On Mon, Dec 30, 2013 at 05:26:19PM +0100, Zbigniew Jędrzejewski-Szmek wrote: > https://bugzilla.redhat.com/show_bug.cgi?id=1047304 > > - if (s->notify_access == NOTIFY_MAIN && pid != s->main_pid) { > + if (s->notify_access == NOTIFY_MAIN && s->main_pid != 0 && pid != > s->main_pid) {
I don't think this patch is correct. It only papers over real issue. The real problem is that systemd sometimes "loses state" during reload/reexec. Colin found the problem in "[systemd-devel] daemon-reload seems racy". When the state is lost, services still run, but things happen: 1) main_pid inside systemd is NULL. For Type=notify services this causes: systemd[1] transmission-daemon.service: Got notification message from PID 1087, but reception only permitted for PID 0 every time service sends notification to systemd 2) "systemctl status <service>" shows the state as DEAD, but the service still run! Cgroup is not empty, network daemons are still bound to sockets and continue to serve request. This state allows admin to issue "systemctl start <service>", but it often fails immediately - because old process is already bound, and new process cannot bind to the same port. "systemctl stop <service>" does not work in this case - systemd thinks <service> is already dead. To clean up, admin has to "systemctl kill <service>" or kill all service's processes manually, followed by "systemctl start". I'm unable to reproduce this behaviour at the moment (systemd-208-9.fc20.x86_64), but I've observed it few times in Fedora 20. -- Tomasz Torcz ,,(...) today's high-end is tomorrow's embedded processor.'' xmpp: zdzich...@chrome.pl -- Mitchell Blank on LKML
pgpDMxv2wmj6t.pgp
Description: PGP signature
_______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
