Bug#727708: upstart proposed policy in Debian [and 1 more messages]
Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
> I don't see the merit in extensibility; or rather, I think that there is
> room in the world for a non-extensible but trivial protocol. (And there
> are other potential simple protocols which would be more extensible.)
Well, the extensibility is already providing another obviously-useful
feature, namely the watchdog support, which is done over the same channel.
How do you think that should be implemented in upstart? It seems like a
good example of a place where a daemon needs an ongoing communication
channel with the init system.
And you're never going to convince me that repurposing SIGSTOP to mean go
is anything other than a hack. Sorry. :) I agree that it's a useful
hack with low impact when patching upstream source, but it's still exactly
the sort of repurposing of one thing to mean something entirely unrelated
that tends to create problems and undermine guarantees that unknown other
parties might be depending on. It makes the standards writer in me
cringe.
I personally have used kill -STOP on daemons started by init before as a
systems administrator, usually when setting up debugging and sometimes
when trying to temporarily pause a daemon while I figure out what's going
on with a load issue without terminating it entirely and losing state. I
believe it's also the first step of a gdb attach. The argument that
admins may use this for other purposes is not theoretical. SIGSTOP is
very useful because it's uncatchable, so you know that daemons with weird
signal handlers can't make it ineffective. It always works the same in
every situation (except, now, with daemons started by upstart). This is
not true of SIGTTOU.
Now, that being said, upstart only cares about SIGSTOP when the job hasn't
yet signaled that it's ready, so this is only an issue if you try to
attach during the early startup stage. That's not an entirely impossible
situation, but less likely and not one of the cases where I've done this
as an administrator before.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: