Which init system for Debian?
Which init system for Debian?
Posted Nov 14, 2013 13:53 UTC (Thu) by anselm (subscriber, #2796)In reply to: Which init system for Debian? by paulj
Parent article: Which init system for Debian?
Not really. A daemon that is started through inetd or xnetd handles one request and then terminates again. Systemd's socket activation starts a service when the socket in question is accessed for the first time, but then the service keeps running and handles future requests without systemd having to re-activate it. With systemd, it makes sense to socket-activate a web server, which would be a very bad idea indeed with inetd/xinetd.
Posted Nov 14, 2013 16:38 UTC (Thu)
by cortana (subscriber, #24596)
[Link]
(For those wanting more information, look at the docs for Accept= in systemd.socket(5).
Posted Nov 14, 2013 16:46 UTC (Thu)
by paulj (subscriber, #341)
[Link] (58 responses)
That's a refinement of socket activation, but the basic principle of super-servers handling socket activation has long existed in Unix. The refinement you mention could be implemented with those too. The general idea of super-servers (socket activated or not) has also long existed, and seen a variety of uses. E.g. to manage terminals, etc.
Posted Nov 14, 2013 20:37 UTC (Thu)
by anselm (subscriber, #2796)
[Link] (56 responses)
Yes, much like a service must be modified to support inetd/xinetd style activation. Systemd can deal correctly with services written for inetd/xinetd, so on a systemd-based system these daemons are no longer required.
Pigs could fly given sufficient thrust. Nobody claims that systemd invented socket activation. It's just that its implementation is considerably more powerful and flexible than that of inetd/xinetd. So far nobody has deigned to retro-fit systemd's socket activation features into inetd or xinetd, and the way things are going as far as systemd adoption is concerned, doing so may no longer be worth the trouble.
It may be worth looking at Lennart Poettering's blog entry on socket activation for more details.
Posted Nov 14, 2013 22:04 UTC (Thu)
by raven667 (subscriber, #5198)
[Link] (3 responses)
This is becoming a trend, everything that systemd does another program could do as well but while the systemd team is implementing, testing, stabilizing and deploying these and other features other software teams haven't even started talking about design yet which makes it seem unfair when comparing systemd to other init systems because they just don't do all of the things that the Linux kernel can do.
Posted Nov 14, 2013 22:17 UTC (Thu)
by anselm (subscriber, #2796)
[Link] (2 responses)
We must compare software systems based on the features that they actually have, not based on the features that they might conceivably have at some point in the future if some unspecified person eventually gets around to designing, implementing, and releasing them.
In that sense systemd is running rings around all the other init systems available today. It may »seem unfair« that systemd is so featureful and cohesive but that is not an accident at all – it is a result of the work that Lennart Poettering, Kay Sievers and their team did over a period of years. In the meantime those who are claiming that »SysV init could so do all of this, too!« have apparently been sitting on their hands. If it is really as easy as you say, then show us the code (and the documentation, examples, …)!
Posted Nov 14, 2013 22:34 UTC (Thu)
by raven667 (subscriber, #5198)
[Link] (1 responses)
Posted Nov 14, 2013 23:41 UTC (Thu)
by anselm (subscriber, #2796)
[Link]
Oh good. I wasn't quite sure :^)
Posted Nov 15, 2013 7:28 UTC (Fri)
by paulj (subscriber, #341)
[Link] (51 responses)
"socket activation also means that you can seamlessly restart a service, a feat which is impossible with Sys5-init."
This is just plainly incorrect, because Unix systems have had super-daemons doing seamless restarting with socket activation for donkey's years now.
I don't have anything against systemd, note. I am *not* arguing against it. However, this meme going that what it does is *only* possible with a kitchen-sink init and that it was impossible pre-systemd is simply wrong. Nothing prevented service management super-daemons being written, and they were. Indeed, if you look at *actual* SysV Unix systems like Unixware and AIX (IIRC), they had a few of them (IIRC - though I can't remember the details), to deal with various different aspects of the system. The basic SysV init took care of ensuring the super-daemons were always running (have we forgotten inittab?), and the super-daemons each managed their services in their own way.
Again, I'm not arguing against systemd, per se. However, an incorrect understanding of history helps no one.
Posted Nov 15, 2013 9:06 UTC (Fri)
by khim (subscriber, #9252)
[Link] (17 responses)
The whole thing is surreal. Lennart explains that some capability is impossible with sysV init and you explain that it's “plainly incorrect” because some other program (not SysV!) had this capability “for donkey's years now”? Some other program not available under Linux, mind you! What's wrong with you, people? Lennart never claimed that all the technologies which he introduced are all genuinely new (indeed, when he explains how they work he writes that it's easy to add them to CUPS because “it already supports launchd-style socket activation”!), he just claims they are new for Linux and are not available in SysV-init! Both facts are quite verifyable correct. Yes, it's true that you can write “superdemons” with socket activation and couple these “superdemons” with Linux version of SysV init. But the fact is: noone did that in all these in all these “donkey's years”. Another fact is: noone did that after systemd introduction. Two these facts pretty much damn SysV init: either Linux version is not capable enough to warrant Unixware and AIX treatment or, alternatively, it does not have enough developers to keep it relevant. In both cases it's good idea to kill it and replace it with some alternative which does have developers and which is kept technocally competitive. Ah, you don't like the fact that he only mentions predecessors in the second part, not upfront? But Lennart is not obligied to do that upfront: that's not a court case and not even a scientific article, that's post in Lennart's blog! He may write what he wants there and of course he will use the most positive description of “his baby”. Why not if the facts are correct?
Posted Nov 15, 2013 9:18 UTC (Fri)
by rahulsundaram (subscriber, #21946)
[Link] (16 responses)
Posted Nov 15, 2013 14:14 UTC (Fri)
by paulj (subscriber, #341)
[Link] (15 responses)
I've no strong opinion either way on systemd. Attempts to make it out as if my comment was in response to some article of Lennart's, which I never mentioned, are trying to straw-man me into some argument I've little care for. Indeed, the polarising nature of Systemd (or is it its developer?) and the fanatical style of debate the topic seems to draw out (either way) is all rather bizarre, I find. People should perhaps examine the level of civility they show.
FWIW, I had taken earlier comments talking about the impossibility of doing certain things under "SysV init" to mean "systems using SysV init", and continued in that vein. The only topic I have an interest in is the question of whether the same Systemd features are possible with a modular system under a SysV init, with functionality distributed over, less tightly-bound components. I think they are, as in my experience such systems have existed before. I disagree only with saying that it's impossible, and only possible with the monolithic Systemd way.
Again, I've no issues with Systemd, no more than with, say, the terminal management daemon in AIX or Unixware, or inetd or Solaris SMF or xinetd, etc. (OK, well, actually, I do have issues with SMF and its use of XML). Systemd seems to be managing services on my system, and the normal chkconfig and services tool interfaces seem to be working.
Note: This post is not generally directed at rahulsundaram.
Posted Nov 15, 2013 15:15 UTC (Fri)
by anselm (subscriber, #2796)
[Link]
The problem with SysV init is that SysV init, as such, doesn't actually do a whole lot at all. Most of what SysV init does, with respect to activating services, is encoded in service-specific (and distribution-specific) shell scripts. We all know that it is possible to make a shell script do pretty much anything. It is also clear that it is possible, in principle, to come up with various clever add-ons to SysV init that do interesting things with services like keeping them running and restarting them if they crash. The downside to this is that no two implementations of SysV init (the base init process plus the init scripts) are quite alike, and that therefore these add-ons, if they do exist, turn out to be fairly insular.
One of the big advantages of systemd in this context is that it tries to provide a single consistent and unified implementation of all the various bits and pieces that could in principle be built on top of SysV init, but which in most cases don't actually exist, and if they in fact do exist usually turn out to be highly system-dependent (or, in the case of Linux, distribution-dependent).
With systemd, we have a real chance of making Linux more consistent, better unified between different distributions, easier to understand, and more versatile. Claiming that most of what systemd does could also be implemented on top of SysV init, while very probably true, does not advance the discussion until the missing code has actually been designed, implemented, debugged, documented, and released under a free license (to fit all the various flavours of SysV init that are out there on various Linux distributions), and that is not likely to ever happen if one goes by the evidence of the last 30 years or so. Systemd, on the other hand, exists already (and is improving all the time), so the »SysV init can do this too« people have some serious catching up to do.
Finally, while we're at it, I can only recommend having a look at The Biggest Myths. The first myth that Lennart Poettering debunks in this article is »systemd is monolithic«.
Posted Nov 15, 2013 15:47 UTC (Fri)
by khim (subscriber, #9252)
[Link] (13 responses)
Where LWN means “Linux Weekly News”. How can you disagree with truth? Yes, it's impossible and it's only possible with the “monolithic systemd way”. Really. Ok. Let's discuss them, then. Note that systemd is not some huge monolythink binary: there are actually many specialized processes, but they all are developed together and are compiled as a large package. Which obviously means that “distributed over, less tightly-bound components” should include packages developed by separate teams and then bound together by packagers. This automatically excludes things like MacOS's launchd and Solaris' SMF (because, you know, they are tightly bound to the specific version of kernel, specific version of SysV init fork, etc). So… what we are discussing here? What “systems [that] have existed before” have you in mind, hmm…?
Yes, if you forget about “distributed over, less tightly-bound components” then you'll find quite a few such systems—but they don't exist under Linux today. Your AIX/MacOS/Solaris/Unixware packages are only interesting as a source of inspiration, they are not ported to Linux and it's not clear if they ever be proted (usually they are tied to some details of the appropriate systems which don't exist on Linux thus you can only use them as an inspiration, the code must be written from scratch or heavily modified). You may as well discuss design decisions of BeOS or Windows: they are just not relevant to discussion in question. You can not simultaneously claim nothing prevented service management super-daemons [from] being written when it's perfectly cleat that they were not written. They were not written in twenty years of Linux history and they were not written in two years which passed after systemd introduction—which means that something is most definitely cause this phenomenon. “Simple to do” things are by definition… well… are simple to do and don't take years and/or decades! It may be technical problems or it may be lack of manpower, whatever. The fact still remains: they are not available today. If you want proper socket activation with seamless restarts, keep-alive capabilities and so on then systemd is the only game in town on Linux. There are other solutions developed for other OSes but they are tightly bound to these OSes and thus are not suitable for Linux distribution.
Posted Nov 15, 2013 19:03 UTC (Fri)
by nix (subscriber, #2304)
[Link] (9 responses)
Posted Nov 15, 2013 19:49 UTC (Fri)
by anselm (subscriber, #2796)
[Link] (8 responses)
inetd and xinetd do exist and they do indeed support a restricted type of socket activation. However, comparing what inetd and xinetd can do to what systemd does is like comparing a bicycle to a fighter jet. They do somewhat strain the notion of »counterexample«.
The other thing is that systemd does what it does with a unified UI that uses the same configuration file structure and command line syntax across all the types of service it supports. From a pragmatic point of view this is a big advantage compared to cobbled-together approaches like »SysV init with inetd/xinetd and loads of custom shell scripts all over«, because apart from its technical advances it makes the system easier to understand, teach, and learn.
On the other hand, the idea of putting layers upon layers of badly-designed stuff on top of SysV init in the name of »loosely coupled modularity« makes for a system that is missing exactly the sort of tight integration that systemd offers, while providing only a subset of the features. People who are new to Linux – and I'm speaking as somebody who teaches Linux system administration for a living – need to get used to various obtuse file formats and directory arrangements like /etc/inittab vs. /etc/inetd.conf (or for that matter /etc/xinetd.conf) vs. /etc/init.d vs. /etc/rc2.d and so on, with distribution-specific tools to do this and that and no attempt at anything like consistency within the system itself, let alone between the implementations that various distributions provide. And that is the great ideal that can do whatever we require and that we need to defend at all costs from newfangled abominations like systemd and Upstart? Please.
Posted Nov 15, 2013 23:51 UTC (Fri)
by nix (subscriber, #2304)
[Link] (5 responses)
Posted Nov 16, 2013 0:04 UTC (Sat)
by khim (subscriber, #9252)
[Link] (4 responses)
Citation needed. Badly. You claim that inetd and xinetd can seamlessly restart a service. Ok. I want to configure service in a mode where it's started when first client is calling it and is transparently restarted after crash (without dropping connections, of course). Nothing fancy, just basic requests which were implementable in Windows NT 3.1 twenty years ago. How to do that with xinetd?
Posted Nov 16, 2013 0:45 UTC (Sat)
by anselm (subscriber, #2796)
[Link] (3 responses)
That is not the business xinetd is in, so it's no big surprise that it can't do it (anymore than it can shine shoes and make coffee).
The problem seems to be that there appear to be several definitions around of what »socket activation« actually means. Inetd/xinetd listen to a socket, and if a connection request comes in they start the daemon in question, which handles the request and then quits. The next connection request causes another instance of the daemon to be started. This of course is terribly inefficient for the kind of service such as HTTP that is not based on long-running sessions, and not especially efficient for services that are, like FTP or SMTP.
Systemd can do this, too, but it also supports a different kind of socket activation where the first connection request causes the daemon to be launched, and then instead of quitting after the request has been handled, the daemon just keeps running to handle any further requests (with no more overhead for extra startups). This is very convenient but inetd/xinetd simply don't do it. Possibly nix knows about some tool based on SysV init that can do that sort of thing, but if it does exist it is certainly not anywhere near mainstream on Linux.
Posted Nov 16, 2013 6:44 UTC (Sat)
by spaetz (guest, #32870)
[Link]
xinetd might be a bicycle, but it does have electric motor and 21 gears...
Posted Nov 16, 2013 17:57 UTC (Sat)
by smurf (subscriber, #17840)
[Link] (1 responses)
All start by actually opening a socket and listen()ing to it. When a connection request arrives,
(a) accept the connection, start a new server, hand the new connection to it on stdin/out. This is, in general, not a good idea because you pay the startup cost for every request.
(b) DO NOT accept the connection; instead, start a new server, hand the listening socket to the server (typically on stdin). Ignore the socket until the server dies. (x)inetd, systemd, upstart, … all can do this.
The condition "the server dies" obviously does not work if the daemon forks-and-exits for whatever reason. xinetd also does not work for you if a server wants to listen to multiple sockets, or (these days) should start when an udev request arrives for it … or maybe you want to manually start the thing because you know you'll need it in a few minutes …
… and shutting it down cleanly has its own grab bag of problems, which (x)inetd does not address AT ALL.
I mean, come on. You can find some piece of code which does a half-assed job of (almost) anything systemd can do . What nobody in this whole discussion has ever mentioned is a program which today improves on anything that systemd can do.
Posted Dec 8, 2013 16:24 UTC (Sun)
by nix (subscriber, #2304)
[Link]
Posted Nov 16, 2013 9:42 UTC (Sat)
by paulj (subscriber, #341)
[Link] (1 responses)
The shell SysV init scripts were indeed a hairball and problematic and racy wrt start. I'm not saying anything to the contrary on that.
All I'm saying is that daemons to monitor resources, launch service handling child processes on demand, and manage their lifetimes (respawning, etc), have a long tradition already in Unix. I'm still curious what it is that can be done in PID 1 wrt child management that is impossible in the more distributed fashion? (And be careful not to conflate what was added to the process management capabilities by cgroups, and used to good effect by systemd, with functionality that is uniquely implementable in PID 1).
(Ob monolithic - Systemd apparently is modular only at compile time, not quite the modular/monolithic distinction I had in mind in my earlier comment).
Posted Nov 16, 2013 14:27 UTC (Sat)
by raven667 (subscriber, #5198)
[Link]
Well everything related to starting and stopping processes using all of the features the Linux kernel provides is in PID 1 but there are other ancillary daemons like udevd, journald, logind and utilities that do various jobs during system startup in /usr/lib/systemd, essentially C programs which replace the system setup logic that all the shell scripts used to do (setting the hostname, mounting filesystems with optional fsck, etc.)
Posted Nov 20, 2013 4:10 UTC (Wed)
by ThinkRob (guest, #64513)
[Link] (2 responses)
Posted Nov 20, 2013 4:43 UTC (Wed)
by raven667 (subscriber, #5198)
[Link] (1 responses)
Posted Nov 21, 2013 0:53 UTC (Thu)
by ThinkRob (guest, #64513)
[Link]
So that makes two different kernels (XNU and FreeBSD) that it's run under. (I know XNU uses FreeBSD code in its kernel, but it's still a pretty different beast.)
Posted Nov 15, 2013 17:26 UTC (Fri)
by smurf (subscriber, #17840)
[Link] (32 responses)
… which did not work particularly well then, and it does so even less now.
You CANNOT reliably (no race conditions, no possibility for strange unexpected stuff in the environment, …) control a service under Unix/Linux/whatever unless you _are_ PID 1 or, at the very least, integrate with init so tightly that using a separate process does not make much sense.
This is a basic fact of Unix/Linux system architecture.
Another problem with these super daemons was (and is) that nobody likes to use them, because they profess to solve one particular problem and leave everything else to … whatever.
systemd tries to solve all problems you're ever likely to encounter when managing your daemons and related jobs (and IMHO mostly successfully, too, but I've written *that* often enough lately).
Posted Nov 15, 2013 22:28 UTC (Fri)
by paulj (subscriber, #341)
[Link] (31 responses)
Posted Nov 16, 2013 17:30 UTC (Sat)
by smurf (subscriber, #17840)
[Link] (30 responses)
Between A and B, however, anything could happen. In particular, the service could have died by itself and something else could have reused its PID. Which is then killed off randomly. Ouch.
This is somewhat fixable if the service is a direct child of PID 1 (by asking init nicely to please kill that specific process -- if you include additional information like e.g. the time it was started). If there's a random service manager in between, you need to talk to that process instead. Assuming that the daemon in question didn't fork. :-/
I can probably think of a couple more races. Or you might ask Lennart – he has probably more to say about this. ;-)
The bottom line is, yes this is all somewhat fixable if you spend enough effort on it, but other than the systemd people _nobody_has_.
Posted Nov 16, 2013 18:28 UTC (Sat)
by paulj (subscriber, #341)
[Link] (3 responses)
However, a super-daemon knows the services it manages, knows the processes it has launched and knows their PIDs. All you do is change the configuration and hey presto. E.g., edit inetd.conf or xinetd.d/$SERVICE and HUP the super-daemon, hey presto. Edit inittab and tell init to reload, etc. Again, other Unixes (SysV ones particularly - AIX had quite a few super-daemon service management things, IVR) took this approach with some success.
It was also quite possible, with the previous, simple Linux init to have it run stuff from inittab. Just run the daemon in the foreground.
The claims that *only* the Systemd kitchen-sink-PID-1 service manager can work reliably still seem unfounded to me.
NB: Claims that the Systemd monolithic way is more unified and more manageable are another thing. That may be the case, but I don't have a strong opinion there. Systemd may well also be a huge improvement on the SysV shell initscripts. I'd appreciate it though if people don't try to put words in my mouth as if I'm arguing otherwise, thanks. :)
Posted Nov 16, 2013 18:32 UTC (Sat)
by paulj (subscriber, #341)
[Link]
Posted Nov 16, 2013 19:45 UTC (Sat)
by smurf (subscriber, #17840)
[Link]
Where did I say that?
The race condition doesn't go away just by rewriting the code in C or whatever.
>> a super-daemon knows the services it manages, knows the processes
It does not know what else these processes forked off, and thus it cannot clean up after them. Don't ask me how often I had to do that manually, for some Apache-FCGI subprocess that got stuck in la-la-land.
Posted Nov 19, 2013 1:18 UTC (Tue)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Systemd solves this nicely by simply slaughtering anything within the service's cgroup.
Posted Nov 16, 2013 19:50 UTC (Sat)
by HelloWorld (guest, #56129)
[Link] (3 responses)
Posted Dec 8, 2013 16:27 UTC (Sun)
by nix (subscriber, #2304)
[Link] (2 responses)
Imagine, over a noisy phone line:
"What PID is that?"
(well, OK, that machine has been forking up a storm for implausibly long. But still. :) )
Posted Dec 8, 2013 17:25 UTC (Sun)
by andresfreund (subscriber, #69562)
[Link]
Posted Dec 8, 2013 19:18 UTC (Sun)
by smurf (subscriber, #17840)
[Link]
… though the main reason against increasing the PID space that much is the ps output's legibility – and human limitations: present-day PIDs 14127 and 14217 are too similar already, so how would you distinguish between 41921160436 and 41921106436?
Posted Nov 17, 2013 19:21 UTC (Sun)
by luto (guest, #39314)
[Link] (21 responses)
It's ugly, it's prone to failure if the service fork-bombs, and it's a bit overcomplicated. That being said, I think it can and should be improved to make it work well.
IMO using control groups for service management is an abomination and should go away. It's a case of using a sledgehammer to drive in a thumbtack, and, even worse, the world is moving in the direction of having only one sledgehammer available. All Unixes have a a process tree -- let's *fix* it and *use* it.
(At work, I use a little Python script to manage services. About twenty lines of code gives me a completely functional way to Ctrl-C the service manager and clean everything up. No privilege required.)
Posted Nov 17, 2013 20:13 UTC (Sun)
by raven667 (subscriber, #5198)
[Link] (20 responses)
Re: Control Groups
There is no extra points for being clever and making a system work that is complicated and prone to failure, using the proverbial sledgehammer to drive the thumbtack is often the correct engineering choice, simple and effective as opposed to high-tech is often a benefit for reliability.
Posted Nov 17, 2013 20:29 UTC (Sun)
by luto (guest, #39314)
[Link] (19 responses)
And making control groups a mandatory requirement for service management has all kinds of problems. The API is acknowledged to be utter crap (it's far worse than PR_SET_CHILD_SUBREAPER), it's far more complicated to use than PR_SET_CHILD_SUBREAPER, it's nonportable and will never be portable, it requires privilege, and it will soon prevent non-systemd uses of control groups.
Continuing the silly analogy, systemd's sledgehammer is not overkill, but it doesn't even work much better than a thumb.
Posted Nov 17, 2013 21:05 UTC (Sun)
by raven667 (subscriber, #5198)
[Link] (18 responses)
I don't believe this is the case, the kernel sends the signal to all processes in the group, they don't have the option of continuing to run and call fork(). http://0pointer.de/blog/projects/systemd-for-admins-4.html
Re: Linux Control Groups
This is an implementation detail on Linux that is different on every kernel and is not part of the application interface. Only programs which need to deal with the underlying kernel plumbing will care and those are almost by definition different for each OS kernel.
Posted Nov 18, 2013 4:54 UTC (Mon)
by dlang (guest, #313)
[Link] (17 responses)
Posted Nov 18, 2013 5:36 UTC (Mon)
by luto (guest, #39314)
[Link] (16 responses)
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:
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.
Posted Nov 15, 2013 6:45 UTC (Fri)
by smurf (subscriber, #17840)
[Link]
Yes. But the same thing holds for inetd -- the service in question needs to know how to handle the fact that its socket is on /dev/stdin.
In any case, inetd's socket thing does not support seamless server restarts, does not support multiple sockets, does not support dbus activation, and neither does it support starting the server on multiple conditions (not events!) (socket- and non-socket based).
The first three limitations also hold for upstart.
Which init system for Debian?
Which init system for Debian?
Which init system for Debian?
That particular aspect of systemd requires the service to be modified to support that mode of operation, doesn't it?
The refinement you mention could be implemented with those too.
Which init system for Debian?
Which init system for Debian?
Which init system for Debian?
Which init system for Debian?
Which init system for Debian?
Which init system for Debian?
Which init system for Debian?
Which init system for Debian?
Which init system for Debian?
Which init system for Debian?
I was responding to anselm, in the comments of this LWN article.
I disagree only with saying that it's impossible, and only possible with the monolithic Systemd way.
The only topic I have an interest in is the question of whether the same Systemd features are possible with a modular system under a SysV init, with functionality distributed over, less tightly-bound components. I think they are, as in my experience such systems have existed before.
Which init system for Debian?
Which init system for Debian?
Which init system for Debian?
Which init system for Debian?
But the fact remains that superdaemons *do* exist, and khim's apparent claim that they don't and are impossible without systemd is simply and factually wrong.
Which init system for Debian?
Which init system for Debian?
*Sigh* There are two way to "socket-activate" a process.
Which init system for Debian?
Which init system for Debian?
Which init system for Debian?
Which init system for Debian?
Which init system for Debian?
Which init system for Debian?
Which init system for Debian?
Which init system for Debian?
Which init system for Debian?
Which init system for Debian?
(Upstart does not know which processes have been forked off by the daemon in question, and thus cannot always shut down a specific service cleanly. systemd uses cgroups to keep track of that information.)
Which init system for Debian?
Which init system for Debian?
Which init system for Debian?
>> it has launched and knows their PIDs.
Which init system for Debian?
Which init system for Debian?
Which init system for Debian?
"41921160436"
"*sigh*"
Which init system for Debian?
Which init system for Debian?
Which init system for Debian?
Which init system for Debian?
> It's ugly, it's prone to failure if the service fork-bombs, and it's a bit overcomplicated.
> It's a case of using a sledgehammer to drive in a thumbtack
As far as I know, using control groups is subject to exactly the same failure: if children (i.e. processes in the control group) appear faster than you can kill them, then you'll never kill them all.
Which init system for Debian?
Which init system for Debian?
> it's nonportable and will never be portable
Which init system for Debian?
Indeed.
Which init system for Debian?
Enumerating processes in the subtree is already possible with /proc/PID/task/TID/children (currently hidden in CONFIG_CHECKPOINT_RESTORE).
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?
Which init system for Debian?
>> to support that mode of operation, doesn't it?