https://bugzilla.novell.com/show_bug.cgi?id=821879 https://bugzilla.novell.com/show_bug.cgi?id=821879#c70 --- Comment #70 from Frederic Crozat <fcrozat@suse.com> 2013-07-22 13:02:14 UTC --- (In reply to comment #69)
(In reply to comment #65)
Just wondering: is it possible to have any "long running" process being run with the udev network rules ? This is no longer possible with systemd / udev in 12.3 (RUN+= shouldn't have anything long running there, systemd unit should be used instead) and udev will kill any process remaining (like an dhcpcd instance) once the script from RUN+ is finished. Feel free to tell me I'm wrong :)
Hmm.. The question is what is "long running" -- the complete boot needs just few secs in both cases. The rule may start some background jobs. AFAIR, the udev rule timeout were much higher.
Here is the exact explanation from upstream NEWS: * udev: when udevd is started by systemd, processes which are left behind by forking them off of udev rules, are unconditionally cleaned up and killed now after the event handling has finished. Services or daemons must be started as systemd services. Services can be pulled-in by udev to get started, but they can no longer be directly forked by udev rules.
I'll take a close look here... when udev kills the background processes that were started via RUN, it could be a reason. But I currently don't believe it is udev related.
The issue is appearing when udev is being upgraded, not systemd, so "something" is going on when udev is being restarted, I think.
There is also something I don't understand: when I look at the journal trace on attachment #3 [details] [details] (with systemd.log_level=debug), it looks like dhcpcd PID and output which is left running is not the one which was initially started:
Jun 06 15:58:25 bwiedemann-12 dhcpcd[750]: eth0: exiting vs Jun 06 16:07:30 bwiedemann-12 dhcpcd[1387]: eth0: received SIGTERM, stopping
It looks like two dhcpcd daemons were started somehow, with one "blocking" the other.
No, dhcpcd were started, after it got a lease it forks continuing in background, while the parent exits [pid 750 above].
ok
I'm also not 100% the issue is caused by active(exited) vs active(running), since upgrading udev package doesn't cause any change at systemd own configuration (no --daemon-reload nor --daemon-reexec in %scripts).
AFAIS, systemd/udev/migration hook kills all processes (using SIGTERM) from the "exited" cgroup. Maybe this happens because it removes background processes started by the RUN rule...?
Hmm, after looking carefully at udev %pre/%post scripts, "systemctl daemon-reload" is being called. It would be interesting to see if just calling "systemctl daemon-reload" is causing the issue (I doubt it). -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.