https://bugzilla.novell.com/show_bug.cgi?id=821879 https://bugzilla.novell.com/show_bug.cgi?id=821879#c69 --- Comment #69 from Marius Tomaschewski <mt@suse.com> 2013-07-22 12:48:06 UTC --- (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. 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.
There is also something I don't understand: when I look at the journal trace on attachment #3 [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].
It would be interesting to have, for the same problematic run (active(exited)), journal trace (journalctl -b, with booting with systemd.log_level=debug) and the network debug trace.
Yes, and perhaps also udev in debug mode too.
Another reminder is network.service (and this kind of initscript) is "abusing" type=forking, since there is no real "daemon" running, nor a PIDFile to help systemd to detect if there is really which PID is the main one.
Yes, it is a drawback is in systemd / RemainOnExit logic for proper systemV script support :-)
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...? Try to enable network tracing, did not show any output, that is there were no "rcnework stop" involved. (In reply to comment #67)
However, I'm not sure this state is the reason why network goes down..
IMO it seems something we have to take a closer look at. -- 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.