[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#727708: requirement of non-forking startup protocol



Ian Jackson <ijackson@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 (rra@debian.org)               <http://www.eyrie.org/~eagle/>


Reply to: