On Thu, 15.05.14 20:57, Brandon Black ([email protected]) wrote: > On Thu, May 15, 2014 at 6:40 PM, Lennart Poettering > <[email protected]>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 _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
