61–70 of 89 posts
Earlier quoted context omitted.
> 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…
> 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 t…
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:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=740509#51
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.
https://www.kernel.org/doc/Documentation/stable_api_nonsense...
If monolithic systems are so obviously inferior, why are micro-kernel implementations of UNIX mostly a historic curiosity?
Earlier quoted context omitted.
Massively overdesigned while trying to solve a problem that almost no one had (network transparency). FreeBSD's implementation of /dev/dsp is a good example of how simple it can be.
Pulseaudio does network audio right and I have been using it for that purpose since it first existed. So from my prospective the mistake was adding in all the other junk. The root cause of all the complexity is (was?) the lack of standardization for hardware interfaces. The lack of some globally usable way of dealing with latency at the OS level is another issue. A thing like Pulseaudio is a natural reaction to the c…
Both PulseAudio and systemd seem to have the "throw everything out, start from a beautiful abstract interface and work down" mentality, which is a recipe for the mess that they've ended up as. Sometimes the best thing to do is pass the ugly complexity one layer up - which is, I think, one of the things that Unix does mostly right.
Earlier quoted context omitted.
> The init portion of systemd reminds me of those days. There is quite a big difference in that systemd was never designed to boot fast - it was designed first and foremost to boot correctly , and the much increased performance was mostly a happy accident of the design they came up with.
This isn't backed up by Lennart's own blog post about the initial Systemd development: > Unfortunately, the traditional SysV init system was not particularly fast. > Another thing we can learn from the MacOS boot-up logic is that shell scripts are [...] slow in execution. > it is also our plan to experiment with systemd not only for optimizing boot times It seems like the real motivation was exactly reversed from you…
At the time Upstart was considered "the future" ... read the comment from Scott James Remnant on this post (unfortunately there doesn't seem to be a way to link to a G+ comment directly?):
https://plus.google.com/+KaySievers/posts/C3chC26khpq
The point is that Upstart's event model was found to be flawed, and the copyright assignment policy meant that fixing Upstart was undesirable.
This explains the filesystem problem (both relevant for reliability and performance) and claims that systemd solves it but Upstart cannot:
https://plus.google.com/+LennartPoetteringTheOneAndOnly/post...
Earlier quoted context omitted.
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 vigorou…
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…
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:
Utility binaries, don't rely directly on PID 1:
/bin/journalctl /bin/loginctl /bin/machinectl /bin/systemctl /bin/systemd-escape /bin/systemd-inhibit /bin/systemd-machine-id-setup /bin/systemd-notify /bin/systemd-tmpfiles /bin/systemd-tty-ask-password-agent /bin/systemd-ask-password /lib/systemd/systemd-ac-power /lib/systemd/systemd-activate /lib/systemd/systemd-backlight /lib/systemd/systemd-binfmt /lib/systemd/systemd-bootchart /lib/systemd/systemd-cgroups-agent /lib/systemd/systemd-cryptsetup /lib/systemd/systemd-fsck /lib/systemd/systemd-initctl /lib/systemd/systemd-modules-load /lib/systemd/systemd-multi-seat-x /lib/systemd/systemd-quotacheck /lib/systemd/systemd-random-seed /lib/systemd/systemd-readahead /lib/systemd/systemd-remount-fs /lib/systemd/systemd-reply-password /lib/systemd/systemd-rfkill /lib/systemd/systemd-shutdown /lib/systemd/systemd-sleep /lib/systemd/systemd-sysctl /lib/systemd/systemd-update-utmp /usr/bin/busctl /usr/bin/hostnamectl /usr/bin/localectl /usr/bin/systemd-analyze /usr/bin/systemd-cat /usr/bin/systemd-cgls /usr/bin/systemd-cgtop /usr/bin/systemd-delta /usr/bin/systemd-detect-virt /usr/bin/systemd-nspawn /usr/bin/systemd-path /usr/bin/systemd-run /usr/bin/systemd-stdio-bridge /usr/bin/timedatectl
Relies on PID 1:
/bin/systemd
Important binaries that rely on systemd, but that don't run on PID 1:
/lib/systemd/systemd-bus-proxyd /lib/systemd/systemd-hostnamed /lib/systemd/systemd-journald /lib/systemd/systemd-localed /lib/systemd/systemd-logind /lib/systemd/systemd-logind-launch /lib/systemd/systemd-machined /lib/systemd/systemd-networkd /lib/systemd/systemd-networkd-wait-online /lib/systemd/systemd-resolved /lib/systemd/systemd-shutdownd /lib/systemd/systemd-socket-proxyd /lib/systemd/systemd-timedated /lib/systemd/systemd-timesyncd /lib/systemd/systemd-user-sessions
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...
But, uh - ever heard of systemctl?
Earlier quoted context omitted.
I challenge you to show me what part of systemd isn't directly related to inititialization of services.
journald, logind. chrooting (nspawn). tty-ask-password-agent.
Earlier quoted context omitted.
It's not. See https://people.debian.org/~stapelberg/docs/systemd-dependenc...
Extremely outdated. In the 15 versions since then, systemd has evolved quite tremendously with too many things to list succinctly.
Earlier quoted context omitted.
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…
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 produc…
Earlier quoted context omitted.
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 produc…
What about systemctl? It talks to systemd-the-PID1 via D-Bus method calls. That the system state is fused with the OS process state remains the case.
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?
Earlier quoted context omitted.
What about systemctl? It talks to systemd-the-PID1 via D-Bus method calls. That the system state is fused with the OS process state remains the case.
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? I…
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?