[systemd-devel] [PATCH 1/2] mising: add __NR_memfd_create syscall number for s390
Signed-off-by: Hendrik Brueckner
---
src/basic/missing.h |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/src/basic/missing.h b/src/basic/missing.h
index dc1f244..93a7cb9 100644
--- a/src/basic/missing.h
+++ b/src/basic/missing.h
@@ -139,6 +139,8 @@ static inline int pivot_root(const char *new_root, const
char *put_old) {
#define __NR_memfd_create 385
# elif defined __aarch64__
#define __NR_memfd_create 279
+# elif defined __s390__
+#define __NR_memfd_create 350
# elif defined _MIPS_SIM
#if _MIPS_SIM == _MIPS_SIM_ABI32
# define __NR_memfd_create 4354
--
1.7.1
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 2/2] udev/path_id: improve and enhance bus detection for Linux on z Systems
From: Liu Yuan Yuan
Improve and enhance the path_id udev builtin to correctly handle bus'
available on Linux on z Systems (s390).
Previously, the CCW bus and, in particular, any FCP devices on it, have
been treated separately. This commit integrates the CCW bus into the
device chain loop. FCP devices and their associated SCSI disks are now
handled through the common SCSI handling functions in path_id.
This implies also a change in the naming of the symbolic links created
by udev. So any backports of this commit to existing Linux distribution
must be done with care. If a backport is requires, a udev rule can be
created to create the "old-style" symbolic links too.
Apart from the CCW bus, this commit adds bus support for the:
- ccwgroup bus which manages network devices, and
- ap bus which manages cryptographic adapters
- iucv bus which manages IUCV devices on z/VM
Signed-off-by: Liu Yuan Yuan
Signed-off-by: Hendrik Brueckner
---
src/udev/udev-builtin-path_id.c | 57 --
1 files changed, 30 insertions(+), 27 deletions(-)
diff --git a/src/udev/udev-builtin-path_id.c b/src/udev/udev-builtin-path_id.c
index 01e2c65..a436e4f 100644
--- a/src/udev/udev-builtin-path_id.c
+++ b/src/udev/udev-builtin-path_id.c
@@ -591,31 +591,23 @@ static struct udev_device *handle_bcma(struct udev_device
*parent, char **path)
return parent;
}
-static struct udev_device *handle_ccw(struct udev_device *parent, struct
udev_device *dev, char **path) {
-struct udev_device *scsi_dev;
+/* Handle devices of AP bus in System z platform. */
+static struct udev_device *handle_ap(struct udev_device *parent, char **path) {
+const char *type, *func;
assert(parent);
-assert(dev);
assert(path);
-scsi_dev = udev_device_get_parent_with_subsystem_devtype(dev, "scsi",
"scsi_device");
-if (scsi_dev != NULL) {
-const char *wwpn;
-const char *lun;
-const char *hba_id;
-
-hba_id = udev_device_get_sysattr_value(scsi_dev, "hba_id");
-wwpn = udev_device_get_sysattr_value(scsi_dev, "wwpn");
-lun = udev_device_get_sysattr_value(scsi_dev, "fcp_lun");
-if (hba_id != NULL && lun != NULL && wwpn != NULL) {
-path_prepend(path, "ccw-%s-zfcp-%s:%s", hba_id, wwpn,
lun);
-goto out;
-}
-}
+type = udev_device_get_sysattr_value(parent, "type");
+func = udev_device_get_sysattr_value(parent, "ap_functions");
-path_prepend(path, "ccw-%s", udev_device_get_sysname(parent));
+if (type != NULL && func != NULL) {
+path_prepend(path, "ap-%s-%s", type, func);
+goto out;
+}
+path_prepend(path, "ap-%s", udev_device_get_sysname(parent));
out:
-parent = skip_subsystem(parent, "ccw");
+parent = skip_subsystem(parent, "ap");
return parent;
}
@@ -627,13 +619,6 @@ static int builtin_path_id(struct udev_device *dev, int
argc, char *argv[], bool
assert(dev);
-/* S390 ccw bus */
-parent = udev_device_get_parent_with_subsystem_devtype(dev, "ccw",
NULL);
-if (parent != NULL) {
-handle_ccw(parent, dev, &path);
-goto out;
-}
-
/* walk up the chain of devices and compose path */
parent = dev;
while (parent != NULL) {
@@ -681,6 +666,25 @@ static int builtin_path_id(struct udev_device *dev, int
argc, char *argv[], bool
parent = skip_subsystem(parent, "scm");
supported_transport = true;
supported_parent = true;
+} else if (streq(subsys, "ccw")) {
+path_prepend(&path, "ccw-%s",
udev_device_get_sysname(parent));
+parent = skip_subsystem(parent, "ccw");
+supported_transport = true;
+supported_parent = true;
+} else if (streq(subsys, "ccwgroup")) {
+path_prepend(&path, "ccwgroup-%s",
udev_device_get_sysname(parent));
+parent = skip_subsystem(parent, "ccwgroup");
+supported_transport = true;
+supported_parent = true;
+} else if (streq(subsys, "ap")) {
+parent = handle_ap(parent, &path);
+supported_transport = true;
+supported_parent = true;
+} else if (streq(subsys, "iucv")) {
+path_prepend(&path, "iucv-%s",
udev_device_get_sysname(parent));
+parent = skip_subsystem(parent, "iucv");
+supported_transport = true;
+supported_parent = true;
}
if (parent)
@@ -7
Re: [systemd-devel] [PATCH 1/2] mising: add __NR_memfd_create syscall number for s390
Applied thanks!
Though I removed the S-o-b line, we don't use that in systemd.
On 09/23/2015 01:42 PM, Hendrik Brueckner wrote:
> Signed-off-by: Hendrik Brueckner
> ---
> src/basic/missing.h |2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/src/basic/missing.h b/src/basic/missing.h
> index dc1f244..93a7cb9 100644
> --- a/src/basic/missing.h
> +++ b/src/basic/missing.h
> @@ -139,6 +139,8 @@ static inline int pivot_root(const char *new_root, const
> char *put_old) {
> #define __NR_memfd_create 385
> # elif defined __aarch64__
> #define __NR_memfd_create 279
> +# elif defined __s390__
> +#define __NR_memfd_create 350
> # elif defined _MIPS_SIM
> #if _MIPS_SIM == _MIPS_SIM_ABI32
> # define __NR_memfd_create 4354
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Running a script as FIRST script before shutdown
Hi list! I'm new here and I hope, I'm in topic... I don't want to develop system, but I didn't found a "system-user"-ML... So, to my problem: I need a possibility to call a script on shutdown/reboot/halt (I use CentOS 7). This **MUST** be the first one be called, since it needs many other service to be running... The second important thing is, that the shutdown-process has to wait until my script ends. Right now I got my script to be called, but: 1) not as first script on shutdown 2) shutdown does not wait, so that my script cannot do what it should... My definition: [Unit] Description=SHUTDOWN oVirt Before=shutdown.target reboot.target halt.target Wants=local-fs.target remote-fs.target network.target [Service] Type=simple ExecStart=/bin/true ExecStop=/usr/local/bin/ovirt-maintenance.sh maintenance RemainAfterExit=yes [Install] WantedBy=multi-user.target Can someone help me? Thanks a lot for your help! Mit freundlichen Grüßen Luca Bertoncello -- Besuchen Sie unsere Webauftritte: www.queo.bizAgentur für Markenführung und Kommunikation www.queoflow.comIT-Consulting und Individualsoftwareentwicklung Luca Bertoncello Administrator Telefon:+49 351 21 30 38 0 Fax:+49 351 21 30 38 99 E-Mail: l.bertonce...@queo-group.com queo GmbH Tharandter Str. 13 01159 Dresden Sitz der Gesellschaft: Dresden Handelsregistereintrag: Amtsgericht Dresden HRB 22352 Geschäftsführer: Rüdiger Henke, André Pinkert USt-IdNr.: DE234220077 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Running a script as FIRST script before shutdown
On Wed, 23.09.15 16:20, Luca Bertoncello (l.bertonce...@queo-group.com) wrote: > Hi list! > > I'm new here and I hope, I'm in topic... I don't want to develop system, but > I didn't found a "system-user"-ML... > > So, to my problem: > I need a possibility to call a script on shutdown/reboot/halt (I use > CentOS 7). This **MUST** be the first one be called, since it needs > many other service to be running... The second important thing is, > that the shutdown-process has to wait until my script ends. There is no concept of "first" or "last" in systemd, since it's not clear what that's supposed to mean if there are multiple, and what happens if some operation results in activation? Hence, simply order your service against the services it requires. If you want to just run some code when shutting down, make it a service with Type=oneshot and RemainAfterExit=yes, give it an empty ExecStart=, but specify ExecStop= to whatever it's supposed to do. Then order it *after* the services that it shall be able to use, as the shutdown order in systemd is always the inverse of the startup order, and what you specify via After= and Before= specifies the startup order. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [HEADS-UP] Please register for systemd.conf 2015 now, only 14 tickets left!
Heya! We are close to being sold out now, only 14 tickets are still available now. If you intend to attend, make sure to register for the conference *now*, before it's too late and all tickets are gone. Register here: https://systemd.events/systemdconf-2015/registration To get an idea about the sessions offered, please see our preliminary schedule: https://systemd.events/systemdconf-2015/schedule Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Disabled event sources / errors on sd-bus break the event loop (Looping too fast)
Krzysztof Kotlenga wrote: > I recommend the following gdb script, because it provides some > possibly interesting output: Slightly fixed version: https://gist.github.com/pocek/709d8c098d632ed1f21e The first one was incorrectly printing pending_iteration instead of prepare_iteration field. Nothing major. > What's going on with order in that "prepare" Prioq? I've debugged this a bit more. Two things: 1. I think prepare_prioq_compare function is wrong: "enabled" field should be the first one to compare. 2. Maybe I don't get something right - please enlighten me if that's the case - but prioq_put or rather shuffle_up function is buggy. Let's start with prepare Prioq like this: bus-input e=1 pri=0 pi=8 fd=12 bus-input e=1 pri=0 pi=9 fd=18 <- netcat Now we enter some garbage in netcat: bus-input e=1 pri=0 pi=9 fd=12 bus-input e=0 pri=0 pi=9 fd=18 <- netcat BTW, some loop iterations later it is still OK if we have fixed the order in prepare_prioq_compare (see 1): bus-input e=1 pri=0 pi=10 fd=12 bus-input e=0 pri=0 pi=9 fd=18 <- netcat Good! Now let's make another connection. We have a breakpoint in prepare_prioq_compare. bus-input e=1 pri=0 pi=11 fd=12 bus-input e=0 pri=0 pi=9 fd=18 (null) e=1 pri=0 pi=0 fd=19 <- new connection, it doesn't have a description set yet. Backtrace for some context (shortened): #0 prepare_prioq_compare (a=0x81466e18, b=0x81477490) #1 shuffle_up (q=0x81466ee8, idx=2) #2 prioq_put (q=0x81466ee8, data=0x81477490, idx=0x814774b8) #3 sd_event_source_set_prepare (s=0x81477490, callback=0x80181f81 ) #4 attach_io_events (bus=0x81476d20) #5 sd_bus_attach_event (bus=0x81476d20, event=0x8140e6e0, priority=0) #6 bus_on_connection (s=0x81471680, fd=14, revents=1, userdata=0x8140e318) #7 source_dispatch (s=0x81471680) #8 sd_event_dispatch (e=0x8140e6e0) #9 sd_event_run (e=0x8140e6e0, timeout=18446744073709551615) #10 manager_loop (m=0x8140e318) #11 main (argc=4, argv=0xbfb1b254) OK, let's see what we have got here: (gdb) p x->prepare_index $2 = 0 (gdb) p y->prepare_index $3 = 2 So we are comparing the new sd_event_source with the first one in the queue. This is bad. Let's move to shuffle_up first. (gdb) frame 1 (gdb) p k $4 = 0 Right. So shuffle_up doesn't iterate more than once here. It has only swapped item 0 and 2. The prepare queue looks like this now: (null) e=1 pri=0 pi=0 fd=19 bus-input e=0 pri=0 pi=9 fd=18 bus-input e=1 pri=0 pi=11 fd=12 It doesn't look like a correct order judging by how prepare_event (sd-event.c) works. The last bus-input above is pretty much broken because s->prepare callback won't be called anymore. Am I wrong to believe that it should have swapped 2 and 1, not 2 and 0? Lennart, can you fix Prioq or correct me if I'm wrong, please? > This has been debugged on v225, but AFAICS master has the same issues. I'm debugging this now on v226 now. -- kjk ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Running a script as FIRST script before shutdown
On Wed, Sep 23, 2015 at 5:20 PM, Luca Bertoncello < l.bertonce...@queo-group.com> wrote: > Hi list! > > I'm new here and I hope, I'm in topic... I don't want to develop system, > but I didn't found a "system-user"-ML... > Yeah, systemd-devel is still also the tech support list. > So, to my problem: > I need a possibility to call a script on shutdown/reboot/halt (I use > CentOS 7). This **MUST** be the first one be called, since it needs many > other service to be running... > Almost always, being "first" is a made up requirement. The actually important part here is "it needs many other services" – and you probably know /which/ specific services it needs, so you can declare them as dependencies in your unit. *(Sometimes takes some trial and error though...)* In systemd, the shutdown order is generally inverse of the boot order – if a unit has "After=X", it will be started after X, but stopped before X. So your unit should have a Requires= (or Wants=) plus an After= for every service it actually needs. Also – the unit seems more like a Type=oneshot, not a Type=simple. -- Mantas Mikulėnas ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Disabled event sources / errors on sd-bus break the event loop (Looping too fast)
Krzysztof Kotlenga wrote: > Two things: > (...) One more. Prioq compare functions in sd-event.c contain this: /* Stability for the rest */ if (x < y) return -1; if (x > y) return 1; How comparing prioq_item.data pointers is going to ensure stability? Shouldn't it be: if (x->prepare_index < y->prepare_index) ... and so on? -- kjk ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] gssd: Improve scalability by not waiting for child processes
Instead of waiting on every fork, which would
become a bottle neck during a mount storm, simply
set a SIGCHLD signal handler to do the wait on
the child process
Signed-off-by: Steve Dickson
---
utils/gssd/gssd.c | 18 ++
utils/gssd/gssd_proc.c | 11 ++-
2 files changed, 20 insertions(+), 9 deletions(-)
diff --git a/utils/gssd/gssd.c b/utils/gssd/gssd.c
index e480349..8b778cb 100644
--- a/utils/gssd/gssd.c
+++ b/utils/gssd/gssd.c
@@ -44,11 +44,13 @@
#define _GNU_SOURCE
#endif
+#include
#include
#include
#include
#include
#include
+#include
#include
#include
#include
@@ -736,6 +738,21 @@ sig_die(int signal)
printerr(1, "exiting on signal %d\n", signal);
exit(0);
}
+static void
+sig_child(int signal)
+{
+ int err;
+ pid_t pid;
+
+ /* Parent: just wait on child to exit and return */
+ do {
+ pid = wait(&err);
+ } while(pid == -1 && errno != -ECHILD);
+
+ if (WIFSIGNALED(err))
+ printerr(0, "WARNING: forked child was killed"
+"with signal %d\n", WTERMSIG(err));
+}
static void
usage(char *progname)
@@ -902,6 +919,7 @@ main(int argc, char *argv[])
signal(SIGINT, sig_die);
signal(SIGTERM, sig_die);
+ signal(SIGCHLD, sig_child);
signal_set(&sighup_ev, SIGHUP, gssd_scan_cb, NULL);
signal_add(&sighup_ev, NULL);
event_set(&inotify_ev, inotify_fd, EV_READ | EV_PERSIST,
gssd_inotify_cb, NULL);
diff --git a/utils/gssd/gssd_proc.c b/utils/gssd/gssd_proc.c
index 11168b2..8f5ca03 100644
--- a/utils/gssd/gssd_proc.c
+++ b/utils/gssd/gssd_proc.c
@@ -656,16 +656,9 @@ process_krb5_upcall(struct clnt_info *clp, uid_t uid, int
fd, char *tgtname,
/* fork() failed! */
printerr(0, "WARNING: unable to fork() to handle"
"upcall: %s\n", strerror(errno));
- return;
+ /* FALLTHROUGH */
default:
- /* Parent: just wait on child to exit and return */
- do {
- pid = wait(&err);
- } while(pid == -1 && errno != -ECHILD);
-
- if (WIFSIGNALED(err))
- printerr(0, "WARNING: forked child was killed"
-"with signal %d\n", WTERMSIG(err));
+ /* Parent: Return and wait for the SIGCHLD */
return;
}
no_fork:
--
2.4.3
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Disabled event sources / errors on sd-bus break the event loop (Looping too fast)
Krzysztof Kotlenga wrote: > 2. Maybe I don't get something right - please enlighten me if that's > the case - but prioq_put or rather shuffle_up function is buggy. > > (...) > > Am I wrong to believe that it should have swapped 2 and 1, not 2 and > 0? OK, I've finally realised that I'm a moron iterating over a heap-like structure... -- kjk ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] failed to change interface name (systemd-networkd)
Hello, Hoping someone can point me in the right direction. I'm attempting to change the interface name (eth0 -> wired) on one of my servers. Here's the output from the journal: ~# journalctl --no-pager | grep -i wired Sep 23 17:11:15 vivid systemd-udevd[399]: error changing net interface name 'eth0' to 'wired0': Device or resource busy Sep 23 17:11:15 vivid systemd-udevd[399]: could not rename interface '2' from 'eth0' to 'wired0': Device or resource busy Sep 23 17:11:17 vivid sh[566]: Unknown interface wired0 Sep 23 17:11:17 vivid systemd[1]: Started ifup for wired0. Sep 23 17:11:17 vivid systemd[1]: Starting ifup for wired0... Here's what the .link contains: # cat 10-ethernet.link [Match] MACAddress=fa:16:3e:31:7a:4b [Link] Name=wired0 MACAddress=fa:15:33:55:33:44 And the .network: # cat 20-ethernet.network [Match] Name=wired* [Network] DNS=8.8.8.8 DNS=8.8.4.4 [Address] Address=10.1.1.190/24 [Route] Destination=0.0.0.0/0 Gateway=10.1.1.1 The MAC address of the interface changes properly, so I know that the unit is at least being read and parsed. As an aside, this is happening on Ubuntu 15.04. I've disabled NetworkManager and am relying, obviously, on systemd-networkd and systemd-resolved. I've also temporarily disabled dhcpd thinking that may have had something to do with the interface being busy, to no avail. Any thoughts on why the interface is busy resulting in the name change failing? Thanks! ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Running a script as FIRST script before shutdown
Hi Lennart, thank you for your answer! > There is no concept of "first" or "last" in systemd, since it's not clear what > that's supposed to mean if there are multiple, and what happens if some > operation results in activation? That's bad... :) > Hence, simply order your service against the services it requires. If you want > to just run some code when shutting down, make it a service with > Type=oneshot and RemainAfterExit=yes, give it an empty ExecStart=, but > specify ExecStop= to whatever it's supposed to do. Then order it *after* the > services that it shall be able to use, as the shutdown order in systemd is > always the inverse of the startup order, and what you specify via After= and > Before= specifies the startup order. Well, this is what I tried for more the three days... :( I know, that the script need at least vdsmd.service, vdsm-network.service and libvirtd.service. But it needs that the tmpfs-partition /run is mounted, too. I didn't found any service or target that mount/unmount /run. How can I specify it? Thanks Mit freundlichen Grüßen Luca Bertoncello -- Besuchen Sie unsere Webauftritte: www.queo.bizAgentur für Markenführung und Kommunikation www.queoflow.comIT-Consulting und Individualsoftwareentwicklung Luca Bertoncello Administrator Telefon:+49 351 21 30 38 0 Fax:+49 351 21 30 38 99 E-Mail: l.bertonce...@queo-group.com queo GmbH Tharandter Str. 13 01159 Dresden Sitz der Gesellschaft: Dresden Handelsregistereintrag: Amtsgericht Dresden HRB 22352 Geschäftsführer: Rüdiger Henke, André Pinkert USt-IdNr.: DE234220077 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] RFC: removing initctl support
Hello all, sorry for the late reply, I've been swamped with other stuff recently. Lennart Poettering [2015-09-22 2:31 +0200]: > a) there's support in systemctl to reboot the system by sending the >right bytes to /dev/initctl as fallback, so that you can reboot a >sysvinit system with "systemctl reboot". We indeed need this for upgrades: If you e. g. install Ubuntu 14.04 LTS (with upstart), or Debian Jessie (with SysV init) and install the systemd packages during the upgrade, you need to be able to reboot into the upgraded system (while upstart/sysvinit is still running). So indeed it's only needed exactly once, but we need to keep this around until at least April 2016 when Ubuntu 16.04 LTS will release (and then we can reasonably assume that systemd will be running for any further upgrades). On Debian it's much harder to give a precise time line as the official project decision is still to support multiple init systems. But if there's a documented workaround, that'd also suffice. > b) There's a mini-daemon "systemd-initctl.service" that is >fifo-activated on /dev/initctl, and forwards reboot requests from >old sysvinit clients to systemd. This direction seems much less important to me -- you can always call "systemctl reboot" while systemd is pid 1, no? > We never even really used this stuff on Fedora properly (since we > actually transitioned from Upstart, not sysvinit, and we never had the > same level of compat for that...). You should run into the same problem if you upgrade an upstart system to systemd, no? You can't possibly exec systemd over upstart in a running system. Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
