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 :)