On (12/08/16 14:34), Victor Tapia wrote:
> 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".
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
You would need to call sd_*notify function after initialisation of responders
man 3 sd_notify
It would solve a problem in a different way.
> 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).
In that case, I think we can merge the patch.
But I would like to do some regression testing with upstart(CentOS6).