Hi Lukas,
I tried to look into systemd documentation and I could not see
anything in documentation which would say that it is a reliable
way to use a pid file. (It might change in future if it is not documented)
man systemd.service says
If set to forking, it is expected that the process configured with
ExecStart= will call fork() as part of its start-up. The parent
process is expected to exit when start-up is complete and all
communication channels are set up. The child continues to run as
the main daemon process. This is the behavior of traditional UNIX
daemons. If this setting is used, it is recommended to also use the
PIDFile= option, so that systemd can identify the main process of
the daemon. systemd will proceed with starting follow-up units as
soon as the parent process exits.
//snip
PIDFile=
Takes an absolute file name pointing to the PID file of this
daemon. Use of this option is recommended for services where Type=
is set to forking. systemd will read the PID of the main process of
the daemon after start-up of the service. systemd will not write to
the file configured here, although it will remove the file after
the service has shut down if it still exists.
It might help for upstart but for systemd it might be better to use
"Type=notify" instead of "Type=forking".
I haven't tried using "Type=notify", but I don't think it would make a
difference if we can't hold the notification signal until the responders
are running.
Is the bug reproducible only with upstart or also with systemd?
For systemd only I would prefer "Type=notify"
I've been able to reproduce this bug in both upstart and systemd, but
the numbers differ significantly (~40% of the runs with upstart, ~1% or
less with systemd).
Kind regards,
Victor