[systemd-devel] PIDFile creation logic

Mantas Mikulėnas grawity at gmail.com
Tue Oct 19 06:09:58 UTC 2021


On Tue, Oct 19, 2021, 08:45 Andrei Borzenkov <arvidjaar at gmail.com> wrote:

> On 18.10.2021 23:08, Silvio Knizek wrote:
> > Am Montag, dem 18.10.2021 um 12:43 -0700 schrieb Kenneth Porter:
> >> I just installed the new-to-EPEL ndppd service and am seeing this in my
> log:
> >>
> >> Oct 17 21:10:08 saruman systemd: Can't open PID file
> >> /var/run/ndppd/ndppd.pid (yet?) after start: No such file or directory
> >>
>
> That is just an information. May be it could be downgraded to debug, at
> least initially.
>
> >> Examining the source, I see that the pidfile is created by the child
> >> process, not the parent. I'm guessing that systemd is expecting the
> pidfile
> >> to exist when the parent exits? (I want to file the issue on the
> upstream
> >> program and want to make sure I understand how this should work.)
> >>
> >> Source in question. Note how daemonize() forks and exits and main()
> invokes
> >> daemonize and then creates the pidfile. I'm thinking that daemonize()
> >> should create the pidfile before it invokes exit().
> >>
> >> <https://github.com/DanielAdolfsson/ndppd/blob/master/src/ndppd.cc>
> >>
> > Hi,
> >
> > just don't demonize and don't use a PIDFile= at all. systemd is
> > actually quite apt in figuring out which process is the right main one.
>
> It is not about "main process". It is about notifying systemd that your
> service is ready and systemd can proceed with After dependencies.
> Without PIDFile your service is "ready" as soon as it forked. This most
> likely is not correct.
>

Not quite as soon as it forked, but as soon as the parent exits.

This doesn't depend on pidfiles, and in general seems to be something that
services get right more often than pidfile creation. Initialize, fork, exit
in parent.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20211019/d495d85a/attachment-0001.htm>


More information about the systemd-devel mailing list