[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#727708: init system other points, and conclusion

On Mon, Dec 30, 2013 at 7:17 PM, Colin Watson <cjwatson@debian.org> wrote:
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.

inotify use can easily be ported to kqueue within Upstart, or libinotify-kqueue can be used.

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

If we are able to settle on a readiness protocol and fully (or almost fully) implement it, then ptrace will become irrelevant. I am sure that if upstream is in agreement on the proto, then Ubuntu and Debian can collaborate to update the jobs (and daemons) for their next releases.

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.

Unity, likely the only desktop environment using Upstart as a session init, is not in Debian. The sacrifice of this functionality on non-linux systems is perfectly acceptable.

There might also be odds and ends around the details of wait status handling.

Two things come to mind: use of epoll in upstart-socket-bridge, and no abstract namespace sockets.

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.

Cameron Norman

Reply to: