[systemd-devel] [PATCH] core/service: check if mainpid matches only if it set

[Tomasz Torcz]

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: zdzichubg at chrome.pl                      -- Mitchell Blank on LKML

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20140214/4728b2f8/attachment.pgp>