Bug#727708: init system other points, and conclusion
On Mon, Dec 30, 2013 at 04:04:05PM -0800, Russ Allbery wrote:
> My belief, and again I welcome concrete reasons why I'm not correct, is
> that adopting upstart poses a similar risk for the Hurd port as adopting
> systemd, and I care just as much about the Hurd port as kFreeBSD. And
> while kFreeBSD is in better shape due to the already-begun upstart port,
> there are still significant porting challenges in the way of maintaining
> feature parity in the kFreeBSD port at the level that it has today. Many
> of those challenges are going to remain regardless of which init system we
> pick.
I haven't looked at this in much detail, and I suspect Dimitri hasn't
yet although IIRC he did express some interest in doing so. But I
haven't seen anyone else try to outline the scope of a port, so let me
try to do so for the sake of general understanding. As far as I know,
the hardest parts would be inotify, ptrace, and prctl
(PR_SET_CHILD_SUBREAPER).
inotify is used to notice changes to configuration files. This is
certainly helpful for users, but it isn't critical as "initctl
reload-configuration" works without it. We could probably do without
this with the aid of a dpkg trigger.
ptrace is used for "expect fork" and "expect daemon"; as I indicated in
another post, I think it would be preferable to avoid these in Debian
and quite possibly to compile them out. (This would mean we wouldn't be
able to translate Ubuntu jobs quite as directly, and a number of
important jobs would definitely need to be changed, but the conversion
isn't usually particularly difficult.)
prctl (PR_SET_CHILD_SUBREAPER) is used to make SIGCHLD notification work
properly when Upstart is supervising a user session. This isn't a
required feature and could easily be compiled out until suitable kernel
support is available (this actually seems like the sort of thing that
could be done in the Hurd without too much difficulty, but I haven't
looked into it). If absent, it might well impede the ability to do an
advanced desktop port, but it wouldn't get in the way of porting the
bulk of services.
There might also be odds and ends around the details of wait status
handling.
So, I'll certainly concede that I haven't actually tried this, but from
what I know of Upstart/libnih's system dependencies, I think that the
Hurd could be accommodated with at worst possibly some loss of
non-critical features.
> I want to mention again something that you'd dismissed as possibly a joke
> earlier, but which I was actually serious about: I think a world in which
> we use systemd on Linux and upstart on non-Linux ports, should upstart
> prove much more portable, actually makes sense. As I said in my other
> writeup, I believe the systemd feature advantage is sufficient to choose
> systemd in isolation, without the other issues discussed. I also believe
> that maintaining a systemd unit plus an upstart configuration is, modulo
> testing (which I realize is a huge issue), much easier than maintaining a
> single sysvinit script.
I wouldn't discard this option out of hand, but I think it would need
significant tool support to be practical (e.g. heuristic generation of
Upstart job files from systemd units), unless we expect all service
maintainers to have kFreeBSD/Hurd VMs lying around. Keeping the
sysvinit scripts and using Upstart as the init daemon is another
possibility, and at least in that case the sysvinit scripts are probably
still lying around. We don't even necessarily have to choose between
those up-front.
--
Colin Watson [cjwatson@debian.org]
Reply to: