[systemd-devel] GuessMainPID=no required to make daemon reload work

[Lennart Poettering]

On Mon, 05.05.14 23:28, Gerd v. Egidy (lists at egidy.de) wrote:

> 
> > Generally, it's not a good idea to keep file locks for a longer period
> > of time... YOu should really just take them while you write a file, and
> > then release them, but not keep them forever...
> 
> I keep the lock on the pidfile as long as the daemon is running. I think this 
> is the best way to prevent a second daemon from running in parallel:
> 
> If the first instance of your program just writes the pid into the pidfile and 
> the second instance reads it and checks if this pid is alive, the first 
> instance could have died ages ago and the pid was reused by another
> program. 

One option is to include the PID "starttime" in the file, as a
protection against collisions.

Note though that systemd actually removes the PID file when a daemon
terminates, a systemd system is hence not vulnerable to this.

But again, it's generally not a good idea to keep file locks for a
longer period of time, much as with mutexes... You don't want to make
other apps which try to get an atomic view on the file hang for long.

Actually, note that anyone who can open a file can take a lock on
it. If the PID file is readable by unpriviliged users taking a lock on
the PID file from the daemon is also an effective way to DoS it
hence. 

Hence, it's probably better to avoid all locking games altogther.

Yes, UNIX sucks...

> Or if the whole system crashes and is rebooted, another program could have 
> been issued the same pid as the daemon had before. So the new instance won't 
> start.

On systemd that's not possible either as /run can only be tmpfs and thus
is flushed on reboot.

Lennart

-- 
Lennart Poettering, Red Hat