Without Systemd
without-systemd.org
without-systemd.org
That said though, I did just recently upgrade to Ubuntu 15.04 (which is all systemd now) and it is noticeably slower to boot up compared to my old upstart-based 14.04 LTS install. Hopefully there's some more optimization that needs to be done to bring the boot-up speed to parity with the previous versions.
Not that I agree, but I believe that's what they said.
What is it that makes uselessd attractive? And why do you consider systemd to be bloated?
- journal
- networkd
- console
Linux has become a victim of it's own success. It's popularity has brought in a new generation of people that learned about computers from Microsoft and Apple and they are bringing the "design" ideas of that world with them because they usually have never learned the basics of what unix is and why so many people use it.
Don't get me wrong - if they want to make a community-developed OS in the windows-style, they should! If that solves their problems better than a unix, then I wish them well and hope the project succeeds. The problem I have is that instead of starting/forking their own project, they are trying to trying to redirect Linux at the expense of those of us that have been here since the kernel 1.2.13 days[2] because it was a unix. Instead of being a separate project, we get to deal with misinformation and bad design, while being labeled a "hater" for wanting to use a working unix instead of the systemd vision of the future[3].
/Sigh/
"Those who do not understand Unix are condemned to reinvent it, poorly." (Henry Spencer)
[1] http://www.catb.org/esr/writings/taoup/html/ch01s06.html
[2] Slackware was already on version 3.0!
GNU/Linux, although historically mostly abiding by Unix principles, has always had syncretic aspects as early as the desktop environments experimenting with various fat RPC protocols over 15 years ago, and likely other precedents earlier.
The introduction of the various storage abstraction layers like devfs and HAL, plus all the other monolithic subsystem daemons in the form of the *kits that emerged early on, foreshadowed what would come today, even if they were mostly manageable back then.
This seems strangely backwards -- a lot of the "let's make this into files" philosophy like devfs, /proc, et. al. borrows from Plan 9, which is arguably more Unix than Unix; systemd on the other hand...
Possibly you are unhappy with binary logs - I'm not very enamoured with them either. Perhaps you don't like the name of that executable. But you can't say it isn't doing the one thing - your issue is not around the Unix philosophy but rather the design decisions of systemd.
> Write programs to handle text streams, because that is a universal interface.
ESR expanded on this in the "Unix Philosophy" chapter of The Art of Unix Programming:
> Unix tradition strongly encourages writing programs that read and write simple, textual, stream-oriented, device-independent formats.
> Before devising a tricky binary format to pass data around, it's worth experimenting to see if you can make a simple textual format work and accept a little parsing overhead in return for being able to hack the data stream with general-purpose tools.
(And no, journalctl and systemd-cat don't fully replace the ability to run text-processing programs like grep, head, tail, etc. directly on the stored data.)
grep, head, tail, etc. work great when you have a small amount of logs. But if you have a production system with lots of logging data, processing plain text can become too slow and/or icky parsing-wise.
6.340s systemd-udev-settle.service
6.232s NetworkManager-wait-online.service
Everything after that is under 250ms or so. Interesting that udev and network manager are taking so long during boot.
udev-settle seems to be a workaround LVM not being event driven enough http://freedesktop.org/wiki/Software/systemd/Optimizations/
https://bbs.archlinux.org/viewtopic.php?id=189369
Using arch, systemd boot time is now almost inexistant (but I have a tiny system with a SSD).
As for NetworkManager's wait online service, see what timeout has been set inside the unit file, and try lowering it. Though I suspect this might be yet another hack implemented as a synchronization point for network-dependent services to initialize properly, given just how finicky it is to define what a "network is up" state actually entails.
It's implemented by Intel and used in many mobiles. It has it's own _absurdly_ fast DHCP client. It manages many network interfaces flawlessly and it's really lightweight. Give it a try.
Most people are cool with that kind of OS, so I don't think there will be much more than occasional grumbling. People like me who can't stand it will all have left.
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 current situation in that it tries to both hide the complexity of the hardware interfaces and deals with the latency issue entirely in one program.
So the problem isn't Pulseaudio. The problem is the environment that media is forced to exist in.
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.
* Mixing several streams in software, if there's no hardware support (th e FreeBSD sound driver does that as well)
* Dynamic switching between several audio interfaces without stopping the stream, e.g. switching to a Bluetooth headset during a phone call
* Reducing power usage by supporting different latencies for each client application, and then running the hardware with the lowest currently requested latency
Best i could find, Poettering started work on Pulseaudio because he picked up a usb headset (basically a usb soundcard with tethered headset) and ran into issues with switching the IO streams around mid-use (say plugging it in while in the middle of a Skype call).
Not sure why he passed on using JACK though, or if it was not mature enough for him at that stage.
Also, i don't think Alsa had dmix (user-space software mixing) at that point in time.
As best i can find the one thing Alsa is missing is a interface other than .alsarc for configuring pr user virtual devices.
That's more than "your implementation" considering that it spans at least ten machines across about the same number of distros including Fedora (and one FreeBSD). But it's cute that you're so quick to say it's "implementation" when it's clearly broken across so many different environments.
Pulseaudio is a stinking pile of shit.
That isn't to say it's been all rosy in Gentoo-land. It was an effort to keep Gnome3 off my system, to keep the existing Gnome2 versions of everything until MATE (and the Gentoo community packaging) was ready enough to replace Gnome2. But my system is happily free of Gnome3, systemd, and pulseaudio. And because Gentoo doesn't really have release versions, I can keep my other packages up to date indefinitely.
One can already see how you at least have to keep the libsystemd package installed on Debian's latest, even if you use something other than systemd as the init etc, or else apt throws a tantrum.
http://ewontfix.com/15/ may be the most interesting read in all this. Notice how everything but dbus and the systemd lib have various issues. And if kdbus hits the kernel, systemd is poised to position itself as the mediator between (legacy) dbus and kdbus.
All in all there is some serious "one true way"-ism coming out of the systemd camp.
However, I think the app-ification they are planning to deploy in Linux systems is extremely dangerous. Essentially they are implementing app bundles as containers [1].
All good lessons learnt from package managers? Gone. Nix? Forgotten.
Imagine a heartbleed like scenario. In a controlled situation with a distro that uses a package manager this is easy to fix. Just upgrade the compromised package. Now think what happens if you have 20 different containers running 20 different userlands...
It's really scary. Linux has become such a nice OS partly because many distros created great package management tools.
These systemd guys make things terribly complex for no reason. Systemd itself is a monster running as PID 1, which is not very wise from a security perspective either. Pulseaudio is slow and unreliable. Dbus is quite inefficient. Etc.
Things are getting ugly. They are messing up with the Linux userland and ignoring core Unix principles.
[1] http://0pointer.net/blog/revisiting-how-we-put-together-linu...
As for kernels and such, at least with Ubuntu Snappy this will be handles in a ChromeOS like fashion. Dump the updated base system into a separate partition, change the Grub config, reboot. If the system fails to boot up it will either instruct the user (i see no admins, nor "power-users" in this scenario) to pick the failsafe/recover option, or do so automatically.
Basically you can forget everything you learned about PC or server. The future is all containers and VMs. The computational equivalent of TV dinners or canned goods.
I have yet to see a convincing argument for this. Is the binary bigger than other inits? Does it do that much more? Link please.
0x0000000000000001 (NEEDED) Shared library: [libsystemd-daemon.so.0]
0x0000000000000001 (NEEDED) Shared library: [libudev.so.1]
0x0000000000000001 (NEEDED) Shared library: [libselinux.so.1]
0x0000000000000001 (NEEDED) Shared library: [librt.so.1]
0x0000000000000001 (NEEDED) Shared library: [libwrap.so.0]
0x0000000000000001 (NEEDED) Shared library: [libpam.so.0]
0x0000000000000001 (NEEDED) Shared library: [libaudit.so.1]
0x0000000000000001 (NEEDED) Shared library: [libcap.so.2]
0x0000000000000001 (NEEDED) Shared library: [libkmod.so.2]
0x0000000000000001 (NEEDED) Shared library: [libdbus-1.so.3]
0x0000000000000001 (NEEDED) Shared library: [libpthread.so.0]
0x0000000000000001 (NEEDED) Shared library: [libc.so.6]
0x0000000000000001 (NEEDED) Shared library: [ld-linux-x86-64.so.2]
What's this about being out of date? Systemd changes very fast, but no additional libraries are linked to and one was changed, and no additional package dependencies required.
I'll have a look at interface changes next.
205:
* systemd-machined daemon added for VMs
* systemd-run utility added for transient units
* added scope, slice and transient units
* some new functions added
206:
* new features added
* no new binaries or files
207:
* new tool for save/restore backlight across reboots added
* variety of tweaks and changed - none effect the interface
208:
* tweaks, bug fixes but no interface changes or additional files/dependencies added
209:
* introduced systemd-networkd component
* systemd-socket-proxy for added to help services that can't support socket-activation natively
* rfkill utility added
* 3 new API headers
210, 211
* no new files, no interface changes, no dependency changes
212:
* systemd-journal-remote added
* some new functions added
* No new dependencies
213:
* new timesync daemon added
* new systemd-resolved added
214:
* Dependency on libattr dropped
215:
* no new files, no interface changes, no dependency change
216:
* networkctl tool added
* systemd-firstboot component added
* bus API changes for PolicyKit
* new library systemd-terminal added
* new tool systemd-journal-upload added
217:
* systemd-consoled daemon added
* multi-seat-x tool removed
218:
* no new files, no dependency changes
219:
* new API sd-hwdb.h added
* systemd-importd for importing container images into nspawn
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.
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.
[1] https://news.ycombinator.com/item?id=9515413
[2] See the "Rule of Modularity": http://www.catb.org/esr/writings/taoup/html/ch01s06.html#id2...
What you're not understanding is that these other binaries do not run as PID 1, 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.
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.
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:
networkd: handles network events - when a network device is created it handles setup. No, it does not supplant udev. Read here an overview: https://coreos.com/blog/intro-to-systemd-networkd/
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.
Or, you can swap out the component: https://fitzcarraldoblog.wordpress.com/2014/09/20/change-sys...
logind handles logins
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.
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.
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?
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?
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?
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.
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.
I've had enough of this nonsense.
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:
0x0000000000000001 (NEEDED) Shared library: [libsystemd-daemon.so.0]
0x0000000000000001 (NEEDED) Shared library: [libudev.so.1]
0x0000000000000001 (NEEDED) Shared library: [libselinux.so.1]
0x0000000000000001 (NEEDED) Shared library: [librt.so.1]
0x0000000000000001 (NEEDED) Shared library: [libwrap.so.0]
0x0000000000000001 (NEEDED) Shared library: [libpam.so.0]
0x0000000000000001 (NEEDED) Shared library: [libaudit.so.1]
0x0000000000000001 (NEEDED) Shared library: [libcap.so.2]
0x0000000000000001 (NEEDED) Shared library: [libkmod.so.2]
0x0000000000000001 (NEEDED) Shared library: [libdbus-1.so.3]
0x0000000000000001 (NEEDED) Shared library: [libpthread.so.0]
0x0000000000000001 (NEEDED) Shared library: [libc.so.6]
0x0000000000000001 (NEEDED) Shared library: [ld-linux-x86-64.so.2]
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.
I've had enough of this nonsense.
That's good to know, so have I :-)
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?
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.
This is exactly the same as the virtualization scenario, where you might have hundreds of possibly vulnerable virtual-machines running under the same virtualization platform (which maybe Linux). Or lots of Docker containers, some of which may have vulnerable software.
App-containerization is usually seen as having security benefits, as it promotes isolation.
Yes, package management tools are great. Containers are also great.
I can imagine a future world in which package management tools understood containers, and could choose how to apply updates (or not!) to nested containers.
Solaris has had this with zones since, IIRC, before Oracle bought Sun.
http://solaris.reys.net/zones-in-solaris-10-part-three-spars...
For OpenSolaris derived products with ipkg, the documentation says that "pkg update" in the global zone will update not only the global zone but all non-global zones as well.
"pulse audio", "gnome 3", etc.
How many people have experience with running systemd based servers in production and, if appropriate, at scale?
Thoughts?
Comparisons with tried and true components like syslog?
Concerning systemd as an init system, it's been extremely reliable and simple to use and manage. Writing unit files, even ones with complex requirements, is incredibly easy, because the FDO documentation is really terrific. For instance, we have a host running docker for services that are contingent on an NFS mount being present on the host: specifying a requirement on the mount-point for the docker service to boot-up is as simple as creating a docker.service.d directory and writing a 2-line drop-in unit file with RequiresMountsFor=/mount/path. Being able to add this functionality so easily, without having to assume total ownership of managing the rest of the service configuration really struck me as exemplary of the reasons systemd won the init wars. It really feels like it bends over backwards to help administrators get shit done, and done right.
Systemd also provides a lot more visibility into service behavior than other init systems i've worked with (logs tailed in status output, exit codes, real pid tracking, etc), which is very helpful in day-to-day work as an administrator. I'm also pretty regulary surprised by how fast our servers reboot, though that's a rather minor benefit. Mount units work just like it says on the tin, not much to report. We haven't started using any of the other systemd stuff like timers, but may do so as we encounter use-cases where it's preferable.
On the flip side, I'm not especially keen on journald. It makes it pretty rough to do system log aggregation out of the box. There's some plans to add the ability to forward logs to a remote server, but it's not there yet on CentOS. Rsyslog has nice integration on CentOS that can help make things resemble a more traditional log structure, but I can't speak to it's viability as we ended up using a more lightweight solution that uses journalds option to forward all message via syslog over a local socket (/run/systemd/journal/syslog) as an input for our log aggregator. It's irritating on occasion, but we've never not been able to work around it, and i'm confident that things will get better going forward, as journald gets more features and more log aggregators add support for polling the journal.
most importantly, i am really looking forward to Ubuntu 16.04 coming out with systemd, at which time Ubuntu, Debian, CentOS and more will all use the same init system in an LTS release. as a regular author of open-source chef cookbooks, it's exciting to think of a future where there's enough x-platform consistency that it's no longer necessary to special-case service management. along this same line, systemd unit aliases are also pretty awesome, and i hope package maintainers in both the rpm and deb world start working to add aliases for divergently named services (apache2 vs httpd, mysql vs mysqld, etc.).
ultimately, we're not dogmatic about the philosophy arguments, most of which at this point strike me as sour grapes. i just want a system that works reliably, is well documented, and makes it easy for me to get shit done. systemd fits that bill better than its predecessors, so we're happy using it until something better comes along :)
Your mention of requirements for service execution is certainly an interesting avenue for me to think about.
Honestly for my day to day "spin up VM, do some experiments/coding, fine tune" it doesn't matter. For some other work I am doing dealing with longer term system maintenance/administration, I've been slow to adapt.
Thanks for the insights.
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.
> 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 your comment - speed first, and correctness as a happy accident.
He does put up a later post (biggest myths about systemd) some three years later which tries to change this impression, but that reads much more like an attempt to move the goalposts than an actual design goal.
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...
I was slowly moving back to FreeBSD from Ubuntu/Debian. Systemd has moved that timing forward. Boot up time and monolithic systems don't do it for me -- managable sure -- but not my cup of tea.