Which init system for Debian?
Which init system for Debian?
Posted Nov 18, 2013 5:36 UTC (Mon) by luto (guest, #39314)In reply to: Which init system for Debian? by dlang
Parent article: Which init system for Debian?
Indeed.
I'd argue that a really good implementation of signal-a-whole-subtree would guarantee that everything gets killed.
I want a set of new kernel features that are actually designed for process subtree management. I'm not sure what the best way to name a subtree is (the pid that started it? -- this has issues if that pid dies (even by OOM) and gets reaped. an fd? -- more complicated.) Aside from the naming issue, I think that the only new operations needed are:
- Signal the whole subtree. Maybe even just SIGKILLing the whole subtree is enough.
- If you're managing a whole bunch of subtrees, a good way to translate from a pid to the subtree that contains that pid could be helpful.
I think that this could be a lot simpler than cgroups.
It would be great if something like this were added to Linux and to *BSD: maybe the systemd people would then consider supporting other operating systems. I don't know of anything other than cgroups that systemd needs that's Linux-specific.
Implementing this should be straightforward, especially if you're willing to accept the kill operation missing things that fork while killing. I think that the only tricky part would be figuring out how to keep track of multiple subtrees per service manager cleanly (and convincing the systemd developers to use it).
Posted Nov 18, 2013 5:46 UTC (Mon)
by dlang (guest, #313)
[Link] (1 responses)
Posted Nov 18, 2013 6:04 UTC (Mon)
by luto (guest, #39314)
[Link]
The benefit is that this would be simple, wouldn't require privilege, and wouldn't require that the One True Cgroup Hierarchy (TM) actually matched the systemd hierarchy. (I have a production system with a cgroup hierarchy that does not match the hierarchy that systemd would come up with. I could probably come up with a mostly equivalent hierarchy that would match, but I don't think that I should need to.)
(You can currently get a working unprivileged service manager because systemd creates /sys/fs/cgroup/systemd/user/UID.user owned by UID. This seems like a suboptimal solution.)
Posted Nov 18, 2013 12:55 UTC (Mon)
by HelloWorld (guest, #56129)
[Link] (12 responses)
Posted Nov 20, 2013 15:34 UTC (Wed)
by foom (subscriber, #14868)
[Link] (11 responses)
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.
Posted Nov 20, 2013 22:43 UTC (Wed)
by HelloWorld (guest, #56129)
[Link] (10 responses)
Posted Nov 20, 2013 23:08 UTC (Wed)
by luto (guest, #39314)
[Link] (9 responses)
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: 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.
Posted Nov 20, 2013 23:57 UTC (Wed)
by rodgerd (guest, #58896)
[Link] (7 responses)
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*.
Posted Nov 21, 2013 5:35 UTC (Thu)
by luto (guest, #39314)
[Link] (5 responses)
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.
Posted Nov 21, 2013 6:10 UTC (Thu)
by raven667 (subscriber, #5198)
[Link] (2 responses)
Posted Nov 21, 2013 9:51 UTC (Thu)
by khim (subscriber, #9252)
[Link] (1 responses)
Posted Nov 21, 2013 13:06 UTC (Thu)
by hummassa (subscriber, #307)
[Link]
Posted Nov 21, 2013 19:26 UTC (Thu)
by smurf (subscriber, #17840)
[Link]
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.
Posted Nov 21, 2013 21:01 UTC (Thu)
by intgr (subscriber, #39733)
[Link]
No, you got it backwards. They're saying that:
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).
Posted Nov 22, 2013 3:56 UTC (Fri)
by foom (subscriber, #14868)
[Link]
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?
Posted Nov 22, 2013 11:06 UTC (Fri)
by jezuch (subscriber, #52988)
[Link]
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).
Posted Nov 18, 2013 15:18 UTC (Mon)
by raven667 (subscriber, #5198)
[Link]
Isn't that the feature Linux Control Groups offers? If you call SIGKILL on a Control Group, I don't think that the processes in that group get a chance to run from the scheduler to be able to call fork() so they are reliably dead. Anything that involves looping over a list in userspace is inherently racy and will fail from a design perspective, that's why using Control Groups and other kernel features is so key to the design of systemd.
I don't think cgroups themselves are terribly complicated, the rate limiters and controllers are complicated but cgroups themselves are simple. I think that is part of the reason why the kernel team is looking to rewrite them, they are _too_ simple and expose too much internal implementation detail.
Which init system for Debian?
Which init system for Debian?
Which init system for Debian?
Systemd also uses inotify and epoll and netlink and literally dozens of other things. A port of systemd to anything other than Linux is simply never going to happen.
Which init system for Debian?
Which init system for Debian?
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.
I can't shake the feeling that this is an odd form of FUD from the systemd people.
Which init system for Debian?
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, ...
Which init system for Debian?
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.
Which init system for Debian?
Which init system for Debian?
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?
Which init system for Debian?
Which init system for Debian?
Assuming that anybody actually wants to do the work, which frankly I doubt – it'd be quite substantial.
Which init system for Debian?
1. Such a port would not be clean.
2. BSD developers wouldn't be interested in adopting systemd anyway.
Which init system for Debian?
Which init system for Debian?
Which init system for Debian?