<div class="gmail_quote"><div dir="ltr">On Thu, May 17, 2018, 12:26 Igor Bukanov <<a href="mailto:igor@mir2.org">igor@mir2.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
I have a service unit for nginx that uses Type=forking and PIDFile.<br>
That works, but occasionally I see in the log a message like<br>
<br>
nginx.service: PID file /run/nginx/nginx.pid not readable (yet?) after<br>
start: No such file or directory<br>
<br>
After investigating this father I see the reason for this is that<br>
nginx creates the pid file in a child process, not in the parent (at<br>
least this is how I interpret their code). As the parent may exit and<br>
systemd may respond to it before the child writes the pid, that leads<br>
to the above message.<br>
<br>
I can workaround that via replacing ExecStart=/usr/sbin/nginx with<br>
something like:<br>
<br>
ExecStart=/bin/sh -c "set -e; /usr/sbin/nginx; while ! test -s<br>
/run/nginx/nginx.pid; do sleep 0.1; done'<br>
<br>
but that busy waits. Is there any option to replace this hack via a<br>
native systemd solution, like explicitly waiting for the pid file to<br>
appear before considering the unit ready?<br></blockquote></div><div><br></div><div>A "native systemd solution" would be to get rid of pidfiles completely.</div><div><br></div><div>Have you tried without the PIDFile= setting at all?</div><div><br></div><div>Maybe socket-activation would work for you? (With Nginx it's also a hack though.)</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><p dir="ltr">Mantas Mikulėnas</p>
</div>