Which init system for Debian?

Posted Nov 20, 2013 15:34 UTC (Wed) by foom (subscriber, #14868)
In reply to: Which init system for Debian? by HelloWorld
Parent article: Which init system for Debian?

inotify, epoll -> kqueue. netlink -> ioctl, usually (not sure exactly what systemd uses it for).

Certainly, you can find a much longer list of linux-specific APIs at Myth #15 on http://0pointer.de/blog/projects/the-biggest-myths.html

However, I do think if you wanted to make a systemd-lite, concentrating only on normal server usage, you could make it work, IF there was a way to watch process trees equivalent to what cgroups gives you.

I mean, when porting it, you can explicitly NOT try to handle a bunch of the other useful features it implements (which, for example, make system startup reliable in the presence of dynamic devices, by allowing mountpoint dependencies). Cut that out, support for network changes, filesystem namespaces, etcetc.

The portability layer would still be annoying, and such a systemd-lite would probably have to be a fork (ala portable openssh), but, I think, entirely feasible.

Which init system for Debian?

Posted Nov 20, 2013 22:43 UTC (Wed) by HelloWorld (guest, #56129) [Link] (10 responses)

> I mean, when porting it, you can explicitly NOT try to handle a bunch of the other useful features it implements (which, for example, make system startup reliable in the presence of dynamic devices, by allowing mountpoint dependencies). Cut that out, support for network changes, filesystem namespaces, etcetc.
If you remove 90% of the functionality of the project, and implement the remaining 10% in another way, then it's not a port. It's a different program sharing a part of the code base.

Which init system for Debian?

Posted Nov 20, 2013 23:08 UTC (Wed) by luto (guest, #39314) [Link] (9 responses)

I can't shake the feeling that this is an odd form of FUD from the systemd people.

At its core, systemd is a service and dependency manager. It supports lots and lots of directives in unit files, most of which could easily be optional. It also supports a bunch of magic to mount things and boot up a Linux system.

I fail to understand what Linux-specific features are needed for the core functionality of acting as PID 1 (e.g. reaping things and setting up controlling ttys) and monitoring services, other than being able to watch subtrees and having something like inotify or fanotify to keep track of configuration.

Here's the list from the systemd myths page:

cgroups, fanotify, umount2(), /proc/self/mountinfo (including notification), /dev/swaps (same), udev, netlink, the structure of /sys, /proc/$PID/comm, /proc/$PID/cmdline, /proc/$PID/loginuid, /proc/$PID/stat, /proc/$PID/session, /proc/$PID/exe, /proc/$PID/fd, tmpfs, devtmpfs, capabilities, namespaces of all kinds, various prctl()s, numerous ioctls, the mount() system call and its semantics, selinux, audit, inotify, statfs, O_DIRECTORY, O_NOATIME, /proc/$PID/root, waitid(), SCM_CREDENTIALS, SCM_RIGHTS, mkostemp(), /dev/input, ...

cgroups: only really needed to watch subtrees.

fanotify, inotify: presumably for watching the configuration directory. I think that all relevant OSes can do this.

mountinfo: only needed if you want mounts.

udev, netlink, /sys: irrelevant -- could easily be turned off (e.g. for systemd --user).

/proc/$PID/whatever: either only needed for logind stuff (which is optional) or (I assume) for diagnostics.

capabilities, namespaces, prctl, selinux, audit: completely irrelevant (again, see systemd --user and/or don't use those features. In any case, systemd clearly does not depend on selinux.)

/dev/input: you're kidding, right? maybe this is needed for logind.

SCM_RIGHTS: not Linux-specific. (and I'm pretty sure that something like SCM_CREDENTIALS is widely supported as well.)

This is getting boring. Given that systemd --user *works*, it seems like it should be relatively easy to configure out most of systemd and to put some kind of portability wrapper around the rest. The main stumbling block seems to be that the systemd people don't want to talk about it.

Which init system for Debian?

Posted Nov 20, 2013 23:57 UTC (Wed) by rodgerd (guest, #58896) [Link] (7 responses)

> The main stumbling block seems to be that the systemd people don't want to talk about it.

The main stumbling block seems to be a lot of people insisting it's possible to create a version of systemd which is portable, or provide all of systemd's functionality with a completely different design, *without any of those people having produced any working code to back up that assertion*.

Which init system for Debian?

Posted Nov 21, 2013 5:35 UTC (Thu) by luto (guest, #39314) [Link] (5 responses)

Sorry to snipe, but I'm sure not going to write that code when the systemd people have said over and over that, even if it were possible to cleanly do such a thing, they wouldn't want it.

My point here is that what systemd is doing with cgroups is ugly and will, once single-hierarchy rules go into effect, suck for a decently large group of users. The kernel could provide a better facility, and everyone (including, most likely, systemd's code complexity) would win if systemd started using it. As a side benefit, if the API were nice, maybe other OSes could adopt it.

Which init system for Debian?

Posted Nov 21, 2013 6:10 UTC (Thu) by raven667 (subscriber, #5198) [Link] (2 responses)

It would make more sense to extend launchd or fork systemd and rewrite the internals for a different OS kernel, maintaining that as a separate project, than to try and add the complexity to systemd of trying to make the internals modular across different OS kernels. I think that's an honest and reasonable technical position to take, presuming an API level of the underlying components (Linux kernel version blah) makes for much simpler programming than if you have to test and fall back for every possible feature incompatibility.

Which init system for Debian?

Posted Nov 21, 2013 9:51 UTC (Thu) by khim (subscriber, #9252) [Link] (1 responses)

Systemd internals are already quite modular and there are many small functions which can be used as points where you may add portbility glue. It's different kind of decision: it's not that Linux offers easier programming model, it's the fact that Linux offers fixed programming model. You don't need to debate how certain function functionality like crypttab or ConditionPathIsMountPoint should be implemnted under different OSes or, more importantly, even if it can be implemented under different OSes! If something is seriously lacking in Linux kernel then it can be added to Linux kernel, after all…

Which init system for Debian?

Posted Nov 21, 2013 13:06 UTC (Thu) by hummassa (subscriber, #307) [Link]

are you arguing that Debian kFreeBSD/HURD/etc should just implement the needed linuxisms (cgroups,etc) in kFreeBSD/HURD/etc? 'cause it actually looks like a nice idea, if anyone should be up to it...

Which init system for Debian?

Posted Nov 21, 2013 19:26 UTC (Thu) by smurf (subscriber, #17840) [Link]

They don't want *BSD and Hurd compatibility code in their source base because it'd be very intrusive in a lot of places. They would have no way to test it and no way to fix it if they should inadvertently break it.

That looks like a perfectly reasonable decision to me, and looking at that list of Linux idioms in systemd I agree that it'd make more sense to fork the thing.
Assuming that anybody actually wants to do the work, which frankly I doubt – it'd be quite substantial.

Which init system for Debian?

Posted Nov 21, 2013 21:01 UTC (Thu) by intgr (subscriber, #39733) [Link]

> I'm sure not going to write that code when the systemd people have said over and over that, even if it were possible to cleanly do such a thing, they wouldn't want it.

No, you got it backwards. They're saying that:
1. Such a port would not be clean.
2. BSD developers wouldn't be interested in adopting systemd anyway.

And because of these 2 reasons, they don't consider any porting effort to be worthwhile to merge/maintain. It would be quite silly to maintain a whole FreeBSD port for the Debian/kFreeBSD people alone.

The goal of systemd has from the start been to unify many of the distro-specific bits, and to be adopted by default across Linux distros. They consider that very unlikely to happen in the BSD world -- that they would adopt a critical core component that's licensed under GPL and led by Linux overlords.

But they are reasonable people. If you could demonstrate them being wrong on both counts, I'm sure they would reconsider. Even if, as you imply, (1) is doable then I would be extremely suspicious about (2).

Which init system for Debian?

Posted Nov 22, 2013 3:56 UTC (Fri) by foom (subscriber, #14868) [Link]

Yes. The fundamental problem is that nobody actually *cares* about having systemd running on FreeBSD, except in that some people seem to see having systemd run on the FreeBSD kernel as a blocker for adopting it on Debian/Linux.

I briefly considered Just Porting It myself, so that the stupid argument about portability could stop, but then I realized: 1) I don't have FreeBSD installed anywhere, and have never run a FreeBSD system, 2) I don't really want to learn how to run/administer FreeBSD, 3) even if I managed to get it to work, I might then get stuck *maintaining* the port which would really suck, and 4) Wait, this whole thing is stupid, I really *really* don't care about FreeBSD -- especially not Debian/kFreeBSD, which almost literally nobody uses. Why was I even considering wasting time on doing something nobody, not even me, actually wants?

Which init system for Debian?

Posted Nov 22, 2013 11:06 UTC (Fri) by jezuch (subscriber, #52988) [Link]

> I fail to understand what Linux-specific features are needed for the core functionality of acting as PID 1

Nothing's "needed". They use these features because they're there, they're useful and there's no point in not using them (except portability, which was commented upon by others).