On (12/08/16 11:48), Victor Tapia wrote:
The attached patch covers ticket #3080
). It's based on the following
Currently, systemd and upstart set the service as 'started' before the
responders are available, making service dependencies (with autofs, for
instance) unreliable due to a race condition with such dependent
services. Creating the pidfile after the responders are up, and
monitoring it's creation in the systemd service fixes this race condition.
Thank you very much for the patch.
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.
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".
Is the bug reproducible only with upstart or also with systemd?
For systemd only I would prefer "Type=notify"