Comment 10 for bug 531912

Mark, I understand you're upset, but your comment is quite unhelpful
really, and the state of GNOME/gnome-shell/Unity and X/Wayland is
entirely irrelevant to Upstart and OpenSSH. Apart from anything else
the people doing the latter have nothing, zero, zilch, nada to do with
the former. If you're upset with Canonical, I'm not sure there's any
point in taking that up with me.

I do plan to figure out some better scripting for this. The real fix
needs Upstart to be able to supervise chroots, which is hard, but it
should be possible to detect the situation in the init.d script and
arrange for some kind of sensible fallback behaviour. If I find time
for that then I will certainly backport the fix to lucid.

It's not accurate to say that the intention of the init.d script was to
provide a wrapper for Upstart in the transition period. The wrapper is
'service', as in 'service ssh start' etc. Normally, the init.d scripts
go away on transitioning to Upstart, but in this case I kept it around
because there was no other way to deal with sshd in a chroot which I
knew to be a common situation. I'm sorry I didn't quite manage to do a
complete job of it, but I really wasn't expecting it to be used as a
wrapper for Upstart when I made those changes.

Regarding what happens when you send SIGHUP to ssh, I think that's
really a separate bug from this one, and it doesn't much help to combine
them. The plan in Upstart for this is to use the proc connector rather
than the short-lived ptrace hack to supervise processes changing pids,
at which point it will be able to notice that sshd now has a new pid and
smoothly switch over to supervising it. The only connection to this bug
is that it might make sense for the init.d script to notice the
situation and do a full restart rather than sending SIGHUP.