On Mon, Dec 30, 2013 at 6:55 PM, Colin Watson <cjwat...@debian.org>
wrote:
The ptrace arrangements used for "expect fork" and "expect daemon"
have
been rather flaky in practice, especially when Upstart jobs are
written
by people not experts in doing so, and they are an obstacle to
portability. I think we should strongly discourage use of these in
Debian in favour of some other readiness protocol. My personal
aesthetic preference is for the "expect stop" scheme or something
close
to it, but I really don't care that deeply and the sd_notify scheme or
similar would work too. Indeed, I might well be inclined to support
disabling the ptrace-requiring features entirely in Debian, and
working
to disable them in Ubuntu in time as well (although that would
require a
transition plan).
For reasons mentioned by Lennart Poettering in his G+ post, I disagree
that expect stop is a good scheme for a readiness protocol. Sure, it is
easy for the daemon and init system, but it is not extensible and can
be harmful when debugging a process (send it a SIGSTOP, init thinks it
is successful and gives it a SIGCONT). NOTIFY_SOCKET is a good scheme
because it is very explicit and can not be misinterpreted by the init
system. In addition, one init system already has implemented it :)
I think Russ has sold me on systemd's journal being a win, at least in
terms of how it enables much better status output for services, and
it's
a shame that something equivalent isn't present in Upstart. My
practical experience of late has been that the per-job log files you
get
by default are good enough for most purposes where I need to debug
service operations, but it certainly isn't all packaged up as neatly.
Now, since two people agree on this, why do we not file a bug in
launchpad asking for the per-job logs to be able to be shown by initctl
(possibly via a --show-logs option)? In fact, I just did it:
https://bugs.launchpad.net/upstart/+bug/1265123.
(P.S. sorry for the sass, it is just so fun :)
Nighty night,
Cameron Norman