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

[Lennart Poettering]

On Thu, 15.05.14 20:57, Brandon Black (blblack at gmail.com) wrote:

> On Thu, May 15, 2014 at 6:40 PM, Lennart Poettering
> <lennart at poettering.net>wrote:
> >
> > 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.
> 
> If they don't want to hang, they don't have to.  There are nonblocking
> calls to check for a conflicting advisory fcntl() lock.  The pidfile should
> be private from random software anyways, other than the daemon itself and
> perhaps whatever tools or init system are managing start/stop.

Note that other programs might read your PID files too, for example
systemd. And systemd won't take a lock on it (we don't want to make PID1
deadlock...). Hence you need to make sure you write those files
atomically anyway, and you cannot use locks for that, you have to use
atomic renames... And if you do that, the locks become pretty useless...

> IMHO, the method of taking an fcntl() writelock on a private pidfile
> is one

Also not that fnctl() (i.e. POSIX) locks are particularly broken
actually, as they are removed whenever close() is invoked by your
process on *any* fds to the file, even if you opened a completely
independent fd. POSIX locks are excessively difficult to use properly,
and in particular if you keep them over longer times...

> of the most reliable methods around for this stuff in the general case
> outside of systemd-land.  AFAIK it's just about the only reliable way that
> doesn't have inherent races or accidentally kill (or be DoS'd by) unrelated
> processes in corner cases.  You don't even have to read the contents
> of the

Umm, no... POSIX locks are not NFS safe, and vulnerable, and really
broken. They are a portability nightmare, and you claim to use them
because of portability.... Also see this:

http://0pointer.de/blog/projects/locking.html

Anyway, this is not the place for discussing the brokeness of Linux file
locking, so let's end this here...

Lennart

-- 
Lennart Poettering, Red Hat