Ian Jackson <ijack...@chiark.greenend.org.uk> writes: > Russ Allbery writes:
>> Yeah, this is a good point. Since systemd uses the daemon-written PID >> file for tracking forking daemons, it doesn't have the same issues as >> the upstart expect fork or expect daemon protocols. Obviously, an >> external PID file is not ideal, but it will work fine with systemd. >> (Now, daemons that don't support a daemon-written PID file either will >> require modifications, but even there, patching the daemon to write a >> PID file may be less intrusive than patching it to change the startup >> behavior.) > I would have expected protocols involving pid files to be racy. Yeah, most daemons that write external PID files have issues with external PID files left from other running instances of the same daemon. (I assume that's what you're talking about.) It's probably possible to avoid that with judicious use of file locking, but that's not common and is more complex. It's not a great long-term solution. But it's certainly no worse than what we have today, where we use daemon-written PID files extensively. I think the issue basically reduces to how much we want to push package maintainers to switch to something more reliable when it requires upstream changes. Personally, I don't think the current problems with PID files written by daemons are sufficiently bad to outlaw them entirely, although I'd certainly encourage upstreams to provide non-forking behavior as at least an option. But maybe it's worse than I realize? Incidentally, systemd's PID guessing support is only needed for daemons that are forking and *don't* write a PID file. It's basically a version of expect daemon, but it's only used when daemons fork and exit and a PID file is not configured. This, like expect fork and expect daemon in upstart, feels to me like something that we don't want to rely on, even if it's occasionally convenient that it exists. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ha9mnh6u....@windlord.stanford.edu
