Re: [systemd-devel] networkd slaac and radv
On Mon, Apr 21, 2014 at 6:57 AM, Vasiliy Tolstov wrote: > 2014-04-11 2:36 GMT+04:00 Vasiliy Tolstov : >> Hello. How can i via networkd can configure network interface to use >> radv provided prefixes? >> For example after boot interface is up and have SLAAC generated >> address (link local) after its receives ra it have global prefix. > > > Anybody knowns? Does it possible and how it possible? Hi Vasiliy, Currently we don't handle this in networkd, sorry. It is on the TODO. Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] networkd slaac and radv
2014-04-21 11:06 GMT+04:00 Tom Gundersen : > Hi Vasiliy, > > Currently we don't handle this in networkd, sorry. It is on the TODO. > > Cheers, Thanks! Does it possible to create some workaround now in my case for this? Or only creating custom unit for network solves this? -- Vasiliy Tolstov, e-mail: v.tols...@selfip.ru jabber: v...@selfip.ru ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] core: add startup resource control option
On 03/26/2014 12:12 AM, WaLyong Cho wrote:
> On 03/25/2014 05:01 AM, Lennart Poettering wrote:
>> On Tue, 25.03.14 01:03, WaLyong Cho (walyong@samsung.com) wrote:
>>
>>> /* Figure out which controllers we need */
>>>
>>> -if (c->cpu_accounting || c->cpu_shares != 1024)
>>> +if (c->cpu_accounting ||
>>> +c->startup_cpu_shares != 1024 ||
>>> +(manager_state(m) != MANAGER_STARTING && c->cpu_shares !=
>>> 1024))
>>
>> This looks incorrect. Shouldn't it be like this:
>>
>> ...
>>
>> if (c->cpu_accounting ||
>> (manager->state(m) == MANAGER_STARTING ? c->startup_cpu_shares :
>> c->cpu_shares) != 1024)
>>
>
> At previous patch, I also wrote similar with your thought. Assume, some
> of units just only specified StartupCPUShares=(or
> StartupBlockIOWeight=). In this case, that unit will not be changed to
> default weight because global state is already changed to running. So I
> put startup_cpu_shares condition alone.
> Obviously, if we just only check condition for "c->startup_cpu_shares !=
> 1024" then that cgroup will always return mask with "CGROUP_CPUACCT |
> CGROUP_CPU".
> If should be NOT then we can make contition using boolean set like this:
>
> if (c->cpu_accounting ||
> (manager_state(m) == MANAGER_STARTING ? c->startup_cpu_shares :
> c->cpu_shares) != 1024 ||
> (manager_state(m) != MANAGER_STARTING && c->startup_cpu_shares_set
> && c->startup_cpu_shares != c->cpu_shares)) {
> mask |= CGROUP_CPUACCT | CGROUP_CPU;
> if (manager_state(m) != MANAGER_STARTING)
> c->startup_cpu_shares_set = false;
> }
>
> But it looks not so good idea.
> Is there any good option?
>
Is there any comments for this?
> ...
>
> Best Regards, WaLyong Cho
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/2] service: add support for reboot argument when triggered by StartLimitAction=
On Tue, Mar 25, 2014 at 02:15:45PM +0100, Michael Olbrich wrote: > When rebooting with systemctl, an optional argument can be passed to the > reboot system call. This makes it possible the specify the argument in a > service file and use it when the service triggers a restart. > This is useful to distinguish between manual reboots and reboots caused by > failing services. Both applied. It seems that our patch queue is getting clogged. Part of the reason has been that Lennart and others have been travelling, and I have been busy with other things. Hopefully things will get better. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-commits] 3 commits - src/libsystemd src/network src/udev
On Sun, Apr 20, 2014 at 10:48 PM, Tom Gundersen wrote:
> On Sun, Apr 20, 2014 at 3:16 PM, Zbigniew Jędrzejewski-Szmek
> wrote:
>> On Sun, Apr 20, 2014 at 05:45:18AM -0700, Tom Gundersen wrote:
>>> commit 6190b9f9d2574428d560458a99f2838041cfdaac
>>> Author: Tom Gundersen
>>> Date: Sun Apr 20 07:51:28 2014 +0200
>>>
>>> sd-rtnl: log when queues are exhausted
>>>
>>> diff --git a/src/libsystemd/sd-rtnl/sd-rtnl.c
>>> b/src/libsystemd/sd-rtnl/sd-rtnl.c
>>> index 8650f55..543bad9 100644
>>> --- a/src/libsystemd/sd-rtnl/sd-rtnl.c
>>> +++ b/src/libsystemd/sd-rtnl/sd-rtnl.c
>>> @@ -203,8 +203,10 @@ int sd_rtnl_send(sd_rtnl *nl,
>>> }
>>> } else {
>>> /* append to queue */
>>> -if (nl->wqueue_size >= RTNL_WQUEUE_MAX)
>>> +if (nl->wqueue_size >= RTNL_WQUEUE_MAX) {
>>> +log_debug("rtnl: exhausted the write queue size
>>> (%d)", RTNL_WQUEUE_MAX);
>>> return -ENOBUFS;
>>> +}
>> Is there a risk of this condition happenning often? Maybe this should be
>> protected
>> by a condition to be printed just once, and then it could be at warning
>> level?
>
> This is extremely unlikely to happen, and if it does surely very bad
> things will result from it (best case the program would fail
> gracefully I suppose). I added this here simply to easily rule out
> this as a source of bugs when debugging similar/related issues.
>
> The reason I didn't make this a higher priority log message is that we
> so far only ever use log_debug from libraries. I don't know if we want
> to start making exceptions to that? Kay, Lennart?
No, we do not want to log from libs, we should still just properly
propagate such errors back from the lib and log from the caller.
Kay
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-networkd bridge with DHCP not working
On Fri, Mar 21, 2014 at 10:15 PM, Tom Gundersen wrote: > On Fri, Mar 21, 2014 at 9:47 PM, Henrik /KaarPoSoft > wrote: >> However, I find it disturbing that DHCP is attempted first on the "wrong" >> MAC, only to be killed and restarted on the "right" MAC. >> Is this really the best way of solving this ??? [...] > What we could do is to force the mac address when creating the bridge > to one we invent ourselves, which (if I read the kernel code > correctly) should then become permanent. I have now implemented this in git, so things should look much better in the next release. At least when the bridges are wholly managed by us. Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] libudev: replace name_to_handle_at with normal sscanf
On Sun, Apr 20, 2014 at 8:08 PM, Zbigniew Jędrzejewski-Szmek
wrote:
> On Sun, Apr 20, 2014 at 03:53:05PM +0200, Kay Sievers wrote:
>> On Sun, Apr 20, 2014 at 5:36 AM, Zbigniew Jędrzejewski-Szmek
>> wrote:
>>
>> > Hi Kay,
>> > it seems that handles are not crucial, and the simplified version below
>> > works too. Is there something I'm missing?
>>
>> The name_to_handle API works properly with bind mounts, it's the more
>> reliable API.
>>
>> It also was intentional to support any filesystem with the prefix
>> devtmpfs*, like "devtmpfs2" or whatever it might be named in the
>> future.
>>
>> What actual problem are we trying to solve here with not requiring a
>> common kernel config option? We want/need it in other places too, and
>> the current fallback logic to figure out the mount point is really not
>> that great with bind mounts. We just need the fallback for filesystems
>> which do not support the API, but most common and tmpfs/devtmpfs do.
>>
>> I don't necessarily see the point in supporting the idea of the
>> kernel's uber-configurability and the massive pain it causes for tools
>> to make things work.
> Yeah, I'm just trying to reduce the confusion that people experience
> on kernels without CONFIG_FHANDLE.
>
> What about this:
>
> 8<-
> Subject: [PATCH] udev: assume /dev is devtmpfs if name_to_handle_at is not
> implemented
>
> We have a bunch of reports from people who have a custom kernel and
> are confused why udev is not running. This raises the possibility of a
> false positive when running on a kernel without CONFIG_FHANDLE but in a
> container. Nevertheless, this caes should be easier to diagnose than
> the opposite of running on bare metal with the same kernel.
I really don't see the problem with hard-requiring a commonly
available kernel feature, especially if it involves returning results
which might be incorrect.
> +log_warning("name_to_handle_at syscall failed,
> assuming /dev is volatile.");
Libraries should never log for normal operation, only debugging is ok.
> +return true;
> +}
>
> +return false;
> +}
>
> f = fopen("/proc/self/mountinfo", "re");
> if (!f)
> @@ -139,8 +146,7 @@ static bool udev_has_devtmpfs(struct udev *udev) {
> continue;
>
> /* accept any name that starts with the currently expected
> type */
> -if (startswith(e + 3, "devtmpfs"))
> -return true;
> +return startswith(e + 3, "devtmpfs");
> }
If we really wanted that kind of fallback, we should falling back to
parsing mountinfo for "devtmpfs" and ignoring the mount_id in this
loop. But since we need that syscall not only here, I don't think we
should do that. We should just explain what we need and simply refuse
to bootup, just like we should refuse to bootup without cgroups
available.
Supporting less reliable operation modes for something that just needs
to be configured in the kernel seems the wrong approach, especially
when it involves filesystem operations on user data like tmpfiles
does, we just depend on CONFIG_FHANDLE.
Kay
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Unit configuration for S3QL filesystem
Hello, I'm trying to create a unit to automatically mount a fuse filesystem known as S3QL, which is the one in question in this older thread: http://lists.freedesktop.org/archives/systemd-devel/2012-May/005062.html. The problem seems to be that after unmounting the filesystem it still needs network access to transfer data. Can someone tell me if it's already possible to create a mount unit configuration that covers this or should I go with a service unit? And if I need a service unit how do I deal with the chance of someone manually unmounting the filesystem thus making (I believe, didn't test it) the service status return successfully when in fact the filesystem's not mounted? I don't know if it's useful, but I'm trying this on Fedora. Thank you in advance, Diogo Vieira Programador Eurotux Informática, S.A. | www.eurotux.com (t) +351 253 680 300 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-networkd bridge with DHCP not working
On Mon, Apr 21, 2014 at 6:45 PM, Tom Gundersen wrote: > On Fri, Mar 21, 2014 at 10:15 PM, Tom Gundersen wrote: >> On Fri, Mar 21, 2014 at 9:47 PM, Henrik /KaarPoSoft >> wrote: >>> However, I find it disturbing that DHCP is attempted first on the "wrong" >>> MAC, only to be killed and restarted on the "right" MAC. >>> Is this really the best way of solving this ??? > > [...] > >> What we could do is to force the mac address when creating the bridge >> to one we invent ourselves, which (if I read the kernel code >> correctly) should then become permanent. > > I have now implemented this in git, so things should look much better > in the next release. At least when the bridges are wholly managed by > us. I spoke too soon. Had to revert that again due to kernel bug... We'll try again when that gets sorted :) Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Cache passphrase for cryptsetup?
On Sat, 19.04.14 13:49, Nikolaus Rath (nikol...@rath.org) wrote: > Hello, > > I have several LUKS encrypted volumes that use the same > passphrase. Before switching to systemd, I have used the decrypt_keyctl > keyscript to cache the passphrase, so that I have to enter it only once. > > As far as I can tell, the systemd cryptsetup generator is ignoring the > keyscript option in /etc/crypttab when creating units. > > Is there another way to achieve passphrase caching with systemd? If you use systemd with plymouth you will get this automaticaly, as plymouth will cache the password for you. There has been a long-standing TODO list item to use the kernel keyring as cache for HDD passwords, and then optionally even open this up to be useful for no-password logins for default users, which can be used to unlock the gnome keyring or suchlike. 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] Unit configuration for S3QL filesystem
On Mon, 21.04.14 19:05, Diogo Vieira (d...@eurotux.com) wrote: > Hello, > > I'm trying to create a unit to automatically mount a fuse filesystem > known as S3QL, which is the one in question in this older thread: > http://lists.freedesktop.org/archives/systemd-devel/2012-May/005062.html. The > problem seems to be that after unmounting the filesystem it still > needs network access to transfer data. Can someone tell me if it's > already possible to create a mount unit configuration that covers this > or should I go with a service unit? And if I need a service unit how > do I deal with the chance of someone manually unmounting the > filesystem thus making (I believe, didn't test it) the service status > return successfully when in fact the filesystem's not mounted? I don't > know if it's useful, but I'm trying this on Fedora. systemd will invoke /bin/mount when mounting a file system, and /bin/umount when unmountin it. fuse file systems may fork off background processes from there, that will be kept around while the file system is mounted, and terminated atfer the file system is unmounted again. 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] mount failed during system start but after "systemctl daemon-reload" everything works
On Fri, 18.04.14 10:32, Oliver (oli...@business-security.de) wrote: > Hello. > Could anyone tell me a reason why a mount (regardless of via fstab > or "mountpoint.mount" unit file) during system boot leads to a > timeout because of device timeout and after i do a "systemctl > daemon-reload" the mount is successful? > > Detailed information: > My system is a Linuxfromscratch 7.5 (so no "real" distribution - > everything is self-compiled) and it runs as a paravirtualized Xen > DomU. Therefore the block devices are /dev/xvda1 and /dev/xvdb1. > The first is the root fs and mount and remount are okay. Then the > second block device should mount and it timed out with "Dependency > failed" and "dev-xvdb1.device/start timed out" > When I run "udevadm info /dev/xvdb1" everything seems to be okay, > but any try of mount this via systemd failes. When I mount manually > via "mount /dev/xvdb1 /mountpoint" it's fine. Then "systemctl status > mountpoint.mount" says "active". > Manually unmount is okay and after this a mount via systemd failes again. > If I do, and only if I do "systemctl daemon-reload" and then > "systemctl start mountpoint.mount" it works. > > I'm a beginner with a systemd based system and do not know much > about the internals. What could lead to this behaviour? Is it > possible that I do anything wrong? > Please help. I'm very frustrated. If you need more Input, please tell me. systemd's .device units rely on the "systemd" tag to be on the udev device, as well as DEVICE_READY=1 being absent of it. I have no idea how xen sets up block device nodes, but what is essential that this used to inform systemd when the devices are ready to be mounted. 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] Persistent timers delay Type=idle units
On Fri, 18.04.14 11:34, Thomas Bächler (tho...@archlinux.org) wrote: > According to [1], when a persistent timer runs its service on boot, it > delays startup. Humm? What precisely do you mean by "delays bootup"? Just scheduling a timer unit should have about zero effect on boot times... If it does this would be a bug. What does "systemctl list-jobs" print when this happens? (i.e. when the bootup is supposedly delayed?) 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] bus driver on kdbus
On Mon, 14.04.14 14:16, Ryan Lortie (de...@desrt.ca) wrote: > Before we realised that this bug was a problem, however, having the bus > driver was clearly closer to "classic dbus-1". Yupp, and we do revisit what we do from time to time and do change our opinions after consideration, which any engineer should do. > > If you want i can put together a "reference implementation" of the > > hashing logic. You'd just pass a list of tokens to add to the hash > > vocabulary, and we return you the match hash. You could then drop that > > into your sources, and you can update it when we do another revision of > > the protocol, and all that without breaking compat. > > I'd actually prefer if you put together a library that was the interface > to kdbus. If it's not possible to have the higher-level logic in the > kernel, then why not have it in userspace? If everyone is using the > same shared library then Well, I am not going to write a second library, you can be sure about that. I really don't understand you anymore I must say. It feels as if you want to play the abstraction game to somehow improve your karma with the freebsd guys, and I really don#t understand at all what the point of that is. YOu know, we can certainly change sd-bus to allow creation of sd_bus_message objects from binary gvariant blobs and fd arrays, but that's just a recipe for bad performance, and creates a huge headache when using the socket backend. It was actually my intention to make sure that the actual kdbus transport was high performance enough too be sueful for gnome apps to transfer bluk data. With such abstraction games you make such a goal incredibly hard. I really don't see why you even want to play this game. Lukas is doing the work on the kdbus port of glib, and he's willing to sheperd the thing into repo, and maintain it. Really, Ryan. Stop playing this stupid abstracted interface game. You are creating a crap platform like that. A big part of what kdbus is about is about minimizing copies for method call transactions. For this we leave memory management and layout of message objects to the sender and copy them together only at the last possible step. By wanting us to do this all for you you kinda force us to either create a complex callback-on-destroy scheme, or to copy early on. I am really strongly against either. > a) we don't have n copies of the bus interface copied everywhere Well, stop pretending that "n" is a large number. It's pretty much 2, not more. One in glib and maybe one in libdbus1, if we want that to speak kdbus directly. sd-bus won't carry one. > We run into trouble if we can have multiple versions of this library Why? > I'd also be open to the idea of defining a new bus type outright and > saying that it's not permitted to send messages to org.freedesktop.DBus > on this new bus type. Aside from my reservations about match rules, I > have no problem with turning GDBus API calls into ioctls (just as you do > in systemd). Sending messages to org.freedesktop.DBus on this new bus > type would fail (since the destination is unknown). This would give app > authors a chance to opt-in to move over to the new bus type and to deal > with compatibility issues as they do so. if this is what it takes... We have to create a new bus type anyway for the system bus, so that apps can acknowledge explicitly that they know how to do their own security. So maybe this is the easiest way out: introduce two new bus types in gdbus and by using those people can acknowledge that they: a) for the system bus are aware they need to do their own security b) for the user bus are aware they might not talk to a session anymore but a user bus c) that they cannot talk to the driver anymore, and need to use gdbus API calls instead And if people do not use the new bus types, we'd simply connect them to the old proxy. 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] [PATCH] systemctl: "systemctl --root=container/ set-default ... is totally borked."
On Thu, 17.04.14 10:40, Jan Chaloupka (jchal...@redhat.com) wrote: > On 04/17/2014 04:59 AM, Zbigniew Je;drzejewski-Szmek wrote: > >On Thu, Apr 17, 2014 at 01:41:51AM +0100, Djalal Harouni wrote: > >>BTW, I've a question, why there is this item in the TODO: > >>"systemctl --root=container/ set-default ... is totally borked." > >> > >>Can someone please shed some light on this? > >I added this, and I guess I should have been more specific, because I had > >to test this again, to see what is wrong :) > > > >systemctl --root=/var/tmp/inst1 set-default multi-user.target > > > >creates a symlink /var/tmp/inst1//usr/etc/systemd/system/default.target -> > >/var/tmp/inst1//lib/systemd/system/multi-user.target, i.e. leaks the > >container name. > If understood correctly, proper symlink should be > > /var/tmp/inst1//usr/etc/systemd/system/default.target -> > /lib/systemd/system/multi-user.target > > Not appending --root prefix in unit_file_search will fix it Hmm, we really should try to generate relative symlinks for cases like this. This is a lot nicer when one browses through an OS tree installed in some subdirectory, since the symlinks then point to the right files, instead of files on the host. 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] [PATCH] systemctl: allow to change the default target without the --force switch
On Mon, 14.04.14 01:07, Djalal Harouni (tix...@opendz.org) wrote: > Currently "systemctl set-default" will fail to change the default target > due to the 'default.target' being a symlink which is always the case. Humm, no? Normally default.target should not exist in /etc, only in /usr. This means "systemctl set-default" should just work if it is run on a pristine system, and only requires --force if there's already user configuration in place that is conflicting. > To work around this, the user must specify the "--force" switch to be > able to overwrite the existing symlink. > > This is clearly a regression that was introduced by commit 718db96199e > since it worked before without the "--force" switch and the man pages do > not mention that you need to specify it. It is expected that this is a > symlink. > > So just explicity set the force flag to make it work again. > > https://bugs.freedesktop.org/show_bug.cgi?id=76623 Hmm, I find the behaviour before this patch actually more sensible, since it treats this symlink like any other symlink we create/remove in install.c. It appears more like a issue of printing a nice error message that informs the user that "--force" might be a good idea to use when this happens... But anyway, my opinion on this isn't very strong, so I am going to leave this patch as is. 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] Systemd askpassword
On Sat, 12.04.14 22:08, Ismael Bouya (ismael.bo...@normalesup.org) wrote: > (Side question: Is there a way to say that systemd-tty-ask-password-agent > can be run by the user and not only by root to mount the disk? If he know > the disk password then he's most probably allowed to mount it...) The GNOME password agent I wrote does support this, but it will do this only via a PoliyKit security transition. I am pretty sure that's necessary because setting up a LUKS volume is a relatively heavy operation, due to the hashing involved. We shouldn't open up such heavy operations to unpriviligied users without involing some kind of auth, so that users cannot simply DoS this. 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] Default file permissions in user mode
On Sat, 12.04.14 12:14, Tanu Kaskinen (tanu.kaski...@linux.intel.com) wrote: > Hi, > > The systemd.socket man page says that the default value for > DirectoryMode is 0755. Judging from the code in the socket_init() > function, the documentation matches the implementation. 0755 seems > appropriate for the system mode, but wouldn't 0700 be better for the > user mode? Likewise for the default socket mode 0666 vs. 0600, and > probably similar permissions are specified elsewhere too. The usual approach for user code is to keep things as closed as necessary and as open as possible and leave the rest to the user with umask or parent directories. 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] Get exit status inside ExecStopPost ?
On Fri, 11.04.14 12:19, Anand Patil (anand.prabhakar.pa...@gmail.com) wrote: > Hi everyone, > > In a service's ExecStopPost, is there an easy way to access the exit status > of the service's ExecStart process? Read the ExecMainCode and ExecMainStatus properties of the Service bus object. They correspond directly to what .si_code and .si_status retuned by waitid(). Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
