> Systemd itself is a monster running as PID 1, which is not very wise from a security perspective either.
No. Only a small part of systemd runs as PID 1. Systemd is not a monolith, it is a bunch of various utilities.
> However, I think the app-ification they are planning to deploy in Linux systems is extremely dangerous.
I agree. This sounds scary. However, it does not mean that distros will hurry to adopt this kind of system. I also get the impression that it is targeted more toward special use cases than intended to replace traditional package managers.
> Pulseaudio is slow and unreliable.
While anecdote is not data, I never had any issue with it.
> Dbus is quite inefficient.
They did not invent Dbus, and using the foremost userland IPC mechanism to communicate is not unreasonable (since, as mentioned above, systemd is a bunch of utilities, they do need some form of IPC). I don't think it has an impact in practice.
> Only a small part of systemd runs as PID 1. Systemd is not a monolith, it is a bunch of various utilities.
Ahh, there's the talking point I mentioned in my earlier post[1].
What you're not understanding is that when we describe something as "monolithic" (or "modular") we're talking about if the design[2], not the number of binaries it happens to compile into. This is about minimizing complexity, and the way to do that is to break the problem into small pieces, while clearly and rigorously defining the interconnections between those pieces (an area that necessarily involves higher complexity).
As an example in the opposite direction, consider busybox. While it compiles into a single binary, the features provided by busybox are very modular. You could remove any of the utilities it can emulate without that change cascading into lots of other unrelated features (with build system support), and I could replace any of the utilities with something else (i.e. the standard non-busybox version) by simply removing a symlink.
Systemd is designed in the opposite manner, on purpose. They put every but of code the project absorbs into the same repository, claiming it makes development easier. Of course it does... initially; you get to skip the all those clearly and rigorously defined interfaces. They can seem like unnecessary work in the beginning, but it is going to be hell maintaining that mess of code in the long run.
> What you're not understanding is that when we describe something as "monolithic" (or "modular") we're talking about if the design[2], not the number of binaries it happens to compile into. This is about minimizing complexity, and the way to do that is to break the problem into small pieces, while clearly and rigorously defining the interconnections between those pieces (an area that necessarily involves higher complexity).
Designs don't run under PID 1, or any other PIDs. Binaries do. You can't both complain about how insecure systemd is because it has a lot of code under PID 1, and then claim that the size of the code actually running under PID 1 is irrelevant.
Many of the binaries provided by systemd indeed have a non-public interface between them, but they are all compile-time optional, with the exception of journald.
Would you say that the people who claim they are migrating to FreeBSD because of systemd are all misguided because FreeBSD, having all of its kernel and userland plumbing in a single repository and tightly coupled, is a monolithic system by design?
Here's a bug on Debian/kFreeBSD about a FreeBSD 10 kernel ABI change breaking ifconfig:
Would you call postfix monolithic too, given that you cannot replace any of its binaries with one from e.g. qmail because the interfaces are different? Is postfix any better than sendmail in this regard?
> They can seem like unnecessary work in the beginning, but it is going to be hell maintaining that mess of code in the long run.
Public interfaces aren't without cost - putting public interfaces where they don't belong is one of the best ways to add accidental complexity to your project and make it much harder to maintain.
If you find some minor design flaw in a non-public interface, you think about what the ideal interface would do, and then you just change the existing interface because you have control of both client and provider of the interface.
If it's a public interface it has to be versioned and you never can remove the implementation of older versions because you have no idea who is using it and what would break, and introducing a new version adds enough extra work that some minor design flaws in the interface will never be fixed because the effort-to-benefit trade-off is different if you have to keep compatibility in mind.
See this article from another successful monolithic project for some good reasons to have internal-only interfaces.
> What you're not understanding is that when we describe something as "monolithic" (or "modular") we're talking about if the design[2], not the number of binaries it happens to compile into.
What you're not understanding is that these other binaries donotrunasPID1, which is what nextos wrongly claimed.
> This is about minimizing complexity, and the way to do that is to break the problem into small pieces, while clearly and rigorously defining the interconnections between those pieces (an area that necessarily involves higher complexity).
Which is the exact opposite of what has happened during the sysvinit times.
> other binaries do not run as PID 1, which is what nextos wrongly claimed.
I never claimed they did. Obviously, I was replying to this claim:
"Systemd is not a monolith, it is a bunch of various utilities."
> Which is the exact opposite of what has happened during the sysvinit times.
I never mentioned anything about sysvinit, which has nothing to do with the bad design in systemd.
Regarding those times, I would agree that the older sysv-rc/initscripts were not that great either, which is why many of us moved to OpenRC a long time ago.
This honestly seems like FUD. Currently the Sys-V like serialisation of services at startup hasn't been efficient, and sysvinit doesn't handle event based kernel features at all well. And it's definitely not modular.
As for this argument that it's monolithic in its code organisation - lolwut? You don't need to have a seperate repository for each binary, hardly anyone does that. When you talk about clearly and vigorously defined interfaces, it seems to already have them - and I hardly consider sysvinit to be a great example of such a thing - a bunch of cobbled together shell scripts serialised into a particular order isn't particularly clean or elegant. Heck, it's not even necessarily easy to troubleshoot if things go wrong. The systemd source is in one git repo, sure, but I can't see why maintenance will be a burden. What in particular concerns you?
You do realize that there are only a few binaries? Let's look at them:
Not a bad idea here: and very sensible aspect of systemd.
journald - collects log data from a variety of sources and puts it into a binary indexed data file. The most controversial aspect of systemd, but of course as is overlooked all the log data can be forwarded to syslog, kmsg, the console or wall via a simple configuration change.
systemd-user-sessions.service allows restricting user logins via PAM
Then there are the systemd units - it handles sockets for socket activation, which is a key reason Debian chose systemd over Upstart. It handles devices via udev, mount points (a key aspect to initialising systems), automount, swap, path-based activation and timers.
I can't see how any of the above should NOT be part of an init system. Init systems should be capable of handling dynamic events. All the technical arguments I've seen so far, with the exception of binary log files, don't hold any water. There are apparently security concerns over PID 1 - but they seem rather specious. Have a look at the dependency list here at https://people.debian.org/~stapelberg/docs/systemd-dependenc... if you don't believe me.
There's a lot of bashing of systemd, but most of it (if not all of it!) is unwarranted and can be verified with even a modicum of research.
As for this argument that it's monolithic in its code organisation - lolwut?
I think what the parent poster meant is that despite being modularized into several components, systemd has interdependencies between them, its individual subsystems not being able to be seamlessly swapped out. Indeed, many components (nspawn included) depend on systemd-as-PID1. As such it is monolithic.
...and I hardly consider sysvinit to be a great example of such a thing - a bunch of cobbled together shell scripts serialised into a particular order isn't particularly clean or elegant.
You're confusing sysvinit with sysv-rc.
You do realize that there are only a few binaries?
Have you actually compiled systemd? The binaries probably exceed a hundred at this point. The count given for 204 was 69.
The most controversial aspect of systemd, but of course as is overlooked all the log data can be forwarded to syslog, kmsg, the console or wall via a simple configuration change.
With two caveats: Forwarding to other sources has a priority loss and doesn't have the same reliability/ordering/completeness guarantees (even if the claim is they "try hard": https://wiki.freedesktop.org/www/Software/systemd/syslog/), journald hijacks /dev/log and expects all syslogd implementations to conform to its own standard.
logind handles logins
Far more than that. It handles user sessions, seats, suspend/hibernate, some device enumeration, gettys and as of recent, system shutdown. It's basically an extension from system init to session init.
it handles sockets for socket activation
Do you even understand what socket activation is? It's a marketing buzzword for an old and simple concept, and the systemd definition in particular conflates multiple use cases. See this commentary by Laurent Bercot: https://forums.gentoo.org/viewtopic-t-994548-postdays-0-post...
It handles devices via udev, mount points (a key aspect to initialising systems), automount, swap, path-based activation and timers.
Mount points and swaps are just small unit wrappers around the mount and swapon/swapoff binaries. It's oversold. Once again, path-based activation is a buzzword for reacting to file system changes, which you can do by leveraging inotify(7) or fanotify(7) independently.
There's pretty powerful cron replacements these days that can take the place of timer units.
I can't see how any of the above should NOT be part of an init system. Init systems should be capable of handling dynamic events.
Those features could be part of a process manager or a process supervisor, not init(8) itself. init(8)'s duties are reaping orphaned processes and handling high-level global system state at best (like SAK, shutdown, halt, etc.) It should not entangle the state of the system with the state of the OS processes, which systemd does quite egregiously. For example, even Apple had the engineering sense to separate their launchd plist configuration parser from the launchd PID1 itself.
How do you define a "dynamic event"?
Have a look at the dependency list here...
Your list is for systemd-204, which is heavily outdated. systemd moves really fast.
There's a lot of bashing of systemd, but most of it (if not all of it!) is unwarranted and can be verified with even a modicum of research.
Too bad it's apparent that you didn't do much of it yourself.
I think what the parent poster meant is that despite being modularized into several components, systemd has interdependencies between them, its individual subsystems not being able to be seamlessly swapped out. Indeed, many components (nspawn included) depend on systemd-as-PID1. As such it is monolithic.
Uh, that's what I would have expected from an init system. And nspawn is for testing and debugging, not for production use.
...and I hardly consider sysvinit to be a great example of such a thing - a bunch of cobbled together shell scripts serialised into a particular order isn't particularly clean or elegant.
You're confusing sysvinit with sysv-rc
No, I was unclear and referring to the source package, which was a bit silly of me. But you knew what I meant.
You do realize that there are only a few binaries?
Have you actually compiled systemd? The binaries probably exceed a hundred at this point. The count given for 204 was 69.
What's your point? Let's look at utility and core binaries:
With two caveats: Forwarding to other sources has a priority loss and doesn't have the same reliability/ordering/completeness guarantees (even if the claim is they "try hard": https://wiki.freedesktop.org/www/Software/systemd/syslog/), journald hijacks /dev/log and expects all syslogd implementations to conform to its own standard.
What? Where are you getting this from? Prove it. You misquote them though, as they say:
"Note that journald tries hard to forward to your BSD syslog daemon as much as it can. That means you will get more than you traditionally got on /dev/log, such as stuff all daemons log on STDOUT/STDERR and the messages that are logged natively to systemd. Also, we will send stuff like the original SCM_CREDENTIALS along if possible."
logind handles logins
Far more than that. It handles user sessions, seats, suspend/hibernate, some device enumeration, gettys and as of recent, system shutdown. It's basically an extension from system init to session init.
You are correct, I was not very clear. Not sure I see the problem here though.
Do you even understand what socket activation is? It's a marketing buzzword for an old and simple concept, and the systemd definition in particular conflates multiple use cases. See this commentary by Laurent Bercot: https://forums.gentoo.org/viewtopic-t-994548-postdays-0-post....
Yup, I do. Interesting comments from Laurent Bercot, unlike you he sees that the idea has merit.
But a few things:
1. He's claiming that Pottering claims to have invented the concept of a superserver, where it was invented in inetd. Small problem: Pottering openly states this in 2011, here: http://0pointer.de/blog/projects/socket-activation.html also he seems to be claiming that Pottering says he invented pre-opened file descriptors? Guy is being a bit of an idiot as Pottering never said this.
2. He's complaining about a registry of predefined sockets in configure files. Seriously? That's his big concern? You deploy a daemon that can do socket-activation and you can't either create a configure file or include one with the package? Wake me up with a real argument, please.
3. He misses the point that socket activation means that you don't have to predefine the service order, by using sockets the service will block till the other service starts. I guess my only concern (that I've just though of) is how systemd handles deadlock conditions, but that isn't a stated concern about reliability by Bercot. Bercot's main concerns are: 1. what happens if a dependent service hangs, and 2. What happens if it's in the middle of a transaction.
I guess my response is: 1. Yes, it will block forever - but if your service was reliant on a serialised startup then I'm not sure what difference this makes: what happens if an earlier service hangs and dependent services can't run until that service has started? That used to happen to me on RedHat 5 when I accidentally forgot to turn off my misconfigured NFS server :-) 2. If you are in the middle of a transaction then again, I can't see how it's any worse than the scenario I just presented.
Those features could be part of a process manager or a process supervisor, not init(8) itself. init(8)'s duties are reaping orphaned processes and handling high-level global system state at best (like SAK, shutdown, halt, etc.)
init doesn't reap orphaned processes, it reaps zombie processes. But actually, there are pretty decent technical reasons for it to handle these duties - like it handles misbehaving daemons that orphan themselves.
It should not entangle the state of the system with the state of the OS processes, which systemd does quite egregiously. For example, even Apple had the engineering sense to separate their launchd plist configuration parser from the launchd PID1 itself.
What... What?
"After the system is booted and the kernel is running, launchd is run to finish the system initialization. As part of that initialization, it goes through the following steps:
It loads the parameters for each launch-on-demand system-level daemon from the property list files found in /System/Library/LaunchDaemons/ and /Library/LaunchDaemons/."
https://developer.apple.com/library/mac/documentation/MacOSX...
What, I answered your questions and that's all you've got? I mean, you've made a few basic mistakes here, like nothing reaps orphaned processes, only zombie processes. And launchd does actually parse plist files directly.
So much for your devastating rebuttal I guess :-) what's your point with dbus by the way? It's just a form of IPC, and uses a bus daemon to transfer the message. Are you implying that's a problem? If so, how?
Fine, I meant orphaned processes get reparented to it by default (unless a subreaper has been defined explicitly via prctl() flag). As for the launchd thing, I'll need to do further research.
Your implication that nspawn isn't for production use strikes me as quite odd. CoreOS based their Rocket platform on it (at least, initially - they might have swappable backends now).
That you expect interdependencies from an init system strikes me as more of a personal bias than anything else, given all the counterexamples - s6, nosh, perp, etc.
Your list of utility binaries that don't directly rely on PID1 is a false one. systemd-activate very much depends on systemd-as-PID1 to perform method call(s) on it, journalctl talks to journald which expects systemd as PID1, systemd-inhibit talks to logind which needs systemd-as-PID1, systemd-readahead is deprecated, systemd-analyze can't possibly work without a systemd PID1 to profile its Manager object, systemd-run needs it, so on and so forth...
I never made a claim that any of those binaries run as PID1... it's pretty obvious only one can be PID1. You're strawmanning too hard.
I haven't tested their claim, that it makes handwavy promises like "tries hard" makes me skeptical. This is hardly the only issue with journald though.
Where the hell did I say that "socket activation" (superservers, fd passing...) is without merit?
I'm pretty sure the escape from predefined service order comes from the dependency system and transaction reordering parts of systemd, not socket activation. Not directly, at least.
I never intended my rebuttal to be "devastating".
And of course, you never did respond to what a dynamic event is, or even my point right now that your assertion about system and process state being separate because systemctl exists is totally wrong... You also didn't respond to your dependency list being outdated, nor my rebuttal to your feature listing about udev devices, mounts, swaps, etc.
Ultimately, it seems like you have a vested interest in defending systemd. That's fine. If it serves you well, all power to you. That all arguments against systemd are misguided as you so boldly claim, is simply wrong.
EDIT: My point is your argument is completely nonsensical. How does controlling systemd from a utility program (like virtually every daemon) rebut my assertion about state?
Ah, the old "you must have a vested interest" argument. Good luck with that. You also haven't raised those counter examples till now.
I've responded to the dependency list being outdated - I asked you to provide me with a later dependency list. I still am - given you stated hundred of binaries, when there aren't I'm curious what you'll come up with!
nspawn isn't for production use, or so says Lennart Pottering, numerous times.
That list of binaries is what is included in Debian Sid unstable. It's not hundreds of binaries. Heck, I've even listed a deprecated one there. If you disagree, it's easy to disprove me: list them.
You quoted the commentary of someone who strongly disagrees with socket activation. I'd assumed you quoted it because you agree. You also asked me if I "even knew what it was", which I do :-)
There is one binary that runs PID 1. The original argument speaks of PID 1 as a key problem, which is the reason most folks don't like systemd.
By dynamic event I mean an event such as a hardware device starting a service, a timer event initialising a service, etc.
Your entanglement argument uses an example that is incorrect, I didn't make this up :-) that's your argument, not mine!
Not all arguments against systemd are misguided. When I first learned systemd ran as PID 1 for what I though was everything, I was concerned. Then I looked into it further and it was all piss and wind, so far as I'm concerned. The one that I find most conducive is binary logs, I'm not a fan. But that seems to be the only thing that even folks like Linus talk about. His real beef is that some of the devs were being dicks, which is really a very Gnome like mentality.
You read into their documentation. They phrase things badly, and those looking for it read into that which I'd not there - like your claims about syslog compatibility, which you can't seem to back up.
Any ctl program needs a way of signalling to the daemon to change its state. Systemd uses dbus: so? What's the issue you have with that?
Init doesn't reap zombied processes, by the way. The kernel does this. Init doesn't do re-parenting either, it just so happens that because it is PID 1 then it's what becomes the parent by default - unless you have a kernel > 3.4 and as you say the child reaper big is set on the parent process.
You seem to have a problem with a process running PID 1 handling dynamic events like hardware changes. I don't think you've given particularly strong reasons why.
Your entire argumentative style in this thread is a combination of reasonable points interspersed with straw men, putting stuff in your opponent's mouth, subtle distortions and willful omissions. I've had enough of it, so this will be my last reply.
I've responded to the dependency list being outdated - I asked you to provide me with a later dependency list. I still am - given you stated hundred of binaries, when there aren't I'm curious what you'll come up with!
Where did I say hundreds? I said -likely- reaching a hundred. Single.
There is no official count - the article you linked was written with a special purpose. Nonetheless, I took an i386 experimental deb for systemd-219 (https://packages.debian.org/experimental/i386/systemd/downlo...) and roughly counted 77. I'm not sure what build was actually run (number could be lower than total), and due to the quick unveiling of new interfaces, the number has been higher at one point. Things move fast at systemd, and the fact that you linked an article measuring 204 as evidence for the present shows you're simply out of touch.
nspawn isn't for production use, or so says Lennart Pottering, numerous times.
Well, then it seems everyone is violating that quite tremendously. CoreOS must be incompetent, I don't know.
It's not hundreds of binaries
Nowhere did I say such.
Your entanglement argument uses an example that is incorrect, I didn't make this up :-)
So the fact that systemd, the PID1 which handles both the system state and the OS process state at the same time, isn't true? Bullshit. Deliberately misreading me to push your agenda.
When I first learned systemd ran as PID 1 for what I though was everything, I was concerned. Then I looked into it further and it was all piss and wind, so far as I'm concerned.
Well, of course. systemd doesn't put everything into PID1. That you're picking to focus on this low fodder argument out of everything that has been said by more acquainted people is just disingenuous.
like your claims about syslog compatibility, which you can't seem to back up.
I never mentioned anything about compatibility with syslogd.
Any ctl program needs a way of signalling to the daemon to change its state. Systemd uses dbus: so? What's the issue you have with that?
Now, this, is a total non sequitur. As in, you completely and horrendously misread everything that I said and deliberately projected your own biases into it. This isn't worth responding to simply because it's based on your own odd incredulity.
Init doesn't reap zombied processes, by the way. The kernel does this. Init doesn't do re-parenting either...
Where the hell did I say any of this? I specifically mentioned they get reparented to init(8), and nothing about zombies. Once again, putting words in my mouth.
Your entire argumentative style in this thread is a combination of reasonable points interspersed with straw men, putting stuff in your opponent's mouth, subtle distortions and willful omissions. I've had enough of it, so this will be my last reply.
I could characterise your responses the same way :-)
Where did I say hundreds? I said -likely- reaching a hundred. Single.
Even over one hundred is way off. There are now 76, I checked myself.
There is no official count - the article you linked was written with a special purpose. Nonetheless, I took an i386 experimental deb for systemd-219 (https://packages.debian.org/experimental/i386/systemd/downlo...) and roughly counted 77. I'm not sure what build was actually run (number could be lower than total), and due to the quick unveiling of new interfaces, the number has been higher at one point. Things move fast at systemd, and the fact that you linked an article measuring 204 as evidence for the present shows you're simply out of touch."
You were close: 76 binaries. Of which the new ones are some extra utilities. Things don't move that fast, and they haven't been increasing their scope - it's stayed pretty much the same as what it was at version 204. I currently have systemd v208 installed, but out of curiousity I checked what libaries it links to:
Then I checked systemd version 219 - exact same libaries.
nspawn isn't for production use, or so says Lennart Pottering, numerous times.
Well, then it seems everyone is violating that quite tremendously. CoreOS must be incompetent, I don't know.
By "everyone", you mean CoreOS, right? CoreOS contribute to systemd, they probably know what they are doing. The man page does say "systemd-nspawn - Spawn a namespace container for debugging, testing and building" and also "Note that even though these security precautions are taken. Many of the security features may be circumvented and are hence primarily useful to avoid accidental changes to the host system from the container." I'd certainly hope anyone who uses it in production had read the man page first. If not, yeah - must be incompetent.
So the fact that systemd, the PID1 which handles both the system state and the OS process state at the same time, isn't true?
Can't follow what you are trying to say here. systemd is not a proposition. Could you restate that?
That you're picking to focus on this low fodder argument out of everything that has been said by more acquainted people is just disingenuous.
"Your entire argumentative style in this thread is a combination of reasonable points interspersed with straw men, putting stuff in your opponent's mouth, subtle distortions and willful omissions."
I never mentioned anything about compatibility with syslogd.
Yeah, you did actually. You said "journald hijacks /dev/log and expects all syslogd implementations to conform to its own standard."
Now, this, is a total non sequitur. As in, you completely and horrendously misread everything that I said and deliberately projected your own biases into it. This isn't worth responding to simply because it's based on your own odd incredulity.
You wrote "For example, even Apple had the engineering sense to separate their launchd plist configuration parser from the launchd PID1 itself.", which is wrong and you admit that you need to look into this more closely. I mentioned systemctl thinking that you believed that launchctl parsed the configuration files for launchd and somehow launchd communicated with this to get the configuration info. Of course, I assumed that's what you thought - otherwise what was your point? systemctl also parses configuration info. Maybe I got the wrong end of the stick, but given you were wrong in the first place I'm not sure what point you were making now.
In this case, it's less that I deliberately misread you, it's more that you weren't very clear!
Init doesn't reap zombied processes, by the way. The kernel does this. Init doesn't do re-parenting either...
Where the hell did I say any of this? I specifically mentioned they get reparented to init(8), and nothing about zombies. Once again, putting words in my mouth.
In case you aren't following along: an orphaned process won't get reaped. You stated that "init(8)'s duties are reaping orphaned processes and handling high-level global system state at best (like SAK, shutdown, halt, etc.)". You probably meant that init reaps zombie processes - you can't reap an orphaned process, an orphaned process is still running and is reparented by the kernel to PID 1. init doesn't do this.
You were therefore wrong on two counts:
1. The kernel detects when a process is orphaned and reparents to PID 1, which just happens to be init. init doesn't actually do any reparenting, which is sort of key to your argument as you believe that init should be the process that reparents a process when it's parent dies.
2. An orphaned process doesn't get reaped, because it's still running. A zombie process is one that has exited but is still in the process table and the parent process hasn't reaped it yet. You don't seem to understand the difference between the two, so I explained it. I'm explaining it again.
No. Only a small part of systemd runs as PID 1. Systemd is not a monolith, it is a bunch of various utilities.
> However, I think the app-ification they are planning to deploy in Linux systems is extremely dangerous.
I agree. This sounds scary. However, it does not mean that distros will hurry to adopt this kind of system. I also get the impression that it is targeted more toward special use cases than intended to replace traditional package managers.
> Pulseaudio is slow and unreliable.
While anecdote is not data, I never had any issue with it.
> Dbus is quite inefficient.
They did not invent Dbus, and using the foremost userland IPC mechanism to communicate is not unreasonable (since, as mentioned above, systemd is a bunch of utilities, they do need some form of IPC). I don't think it has an impact in practice.