No more problems with overflowing logfiles, no more debugging undocumented shell scripts for booting, no more writing init scripts, no more debugging undocumented 200+ line init scripts, no more minute-long boot delays, no more brittle, half-assed distribution-specific networking solutions (also undocumented shell scripts), ...
For me as sysadmin, systemd solved a lot of long-standing problems, while so far introducing no new ones.
I think systemd has the misfortune/honor of touching decades-old subsystem interfaces. Any time anyone ever makes a change to something that's worked the same forever faces criticism. systemd's feature set is so attractive that it's getting/gotten adopted by the vast majority share of linux distros. The folks who didn't prefer it but thought that they could ignore it may have been surprised and vocal when it showed up in their favorite distro.
>undocumented 200+ line init scripts ... undocumented shell scripts
Maybe we've just traded those for undocumented C init programs?
Note: I KNOW that documentation is seriously hard. But, one of the rebuttals of the "Systemd is complex and monolithic" assertion is "Systemd is fully documented, so you can replace any part of it with one that you've authored.". You can't honestly make that rebuttal if the state of your documentation doesn't support your claim.
Oh, you summer child.
In any complex software project, there's always a difference between the contract described by the system's specification and the contract described by the software as implemented.
The big difference between the explicit contract of the documentation and implicit contract of the code is that -in areas on which the documentation is silent- the contract described by the code is subject to change at any time, without warning. Raymond Chen [0] has spilled much ink over customers who have gotten badly burned by changes in the implicit contract some time after they made use of something that the code permitted, but the documentation did not describe as possible and/or supported.
[0] Microsoft most notable backwards-compatibility guru
That's exactly the reason why source itself is better than implementation documentation - because it is always "current".
If user behaviour doesn't change - why changes in implementation are wrong? Reimplementations can use the source code at one place in time and use that as a reference.
Not quite. The journal is prone to fragmentation, though it can be capped just as most sane loggers like multilog can.
no more debugging undocumented shell scripts for booting
no more writing init scripts
no more debugging undocumented 200+ line init scripts
Redundant complaints, and irrelevant. Not all script-based init systems are created equal, and many init systems throughout history have eschewed shell scripts [1].
no more minute-long boot delays
Incorrect. Boots can still stall from dependency loops, cyclical transactions, stuck start/stop jobs, an improperly calculated service ordering in the parallel dependency graph, etc.
no more brittle, half-assed distribution-specific networking solutions (also undocumented shell scripts)
Incorrect. networkd is tailored to specific purposes (largely containers) and not a general-purpose NetworkManager replacement, nor does it necessarily deprecate any ad-hoc network configuration scripts (which aren't even intrinsically bad).
> The journal is prone to fragmentation, though it can be capped just as most sane loggers like multilog can.
So my choices are a) systemd + journald, which Just Works™ by always feeding units' stdout to it without any further configuration, b) syslog and logrotate and oh I have to patch software to use syslog in the first place and make sure logrotate rotates the files correctly if a daemon still its logfile open and… yeah, screw that, I've wasted enough of my life with that, c) something where I manually set up everything to use multilog.
> Redundant complaints, and irrelevant
From your ivory tower, maybe. Meanwhile I'm sitting in the trenches and banging my head against the wall because someone again managed to break their 300+ line init script (hi, MySQL!).
> Incorrect.
I did not mean failure cases. The average case, where every service starts up in a correct order on sysvinit/systemd, went from ~60 seconds to <20. Now, a reboot is usually faster than the failover timeout.
And unlike with Debian's "dependency-based sysvinit", systemd works. I've yet to see a failure case that wasn't caused by either hardware failure or gross operator error (e.g. referencing /var wrong in the fstab).
> Incorrect.
Well, it looks I have to throw away my perfectly working networkd setups then, if you say so.
> NetworkManager
I wasn't even talking about that. I was mainly referring to Debian's networking scripts (which have been broken and unfixed for half a decade now) and Arch's netcfg/netctl which all three never worked as advertised. If NetworkManager was actually usable on headless devices, I might prefer it over networkd, too (assuming I find a use case where either it or connman are insufficient).
No, but those of us who do generally get downvoted for mentioning it in these comment threads, so many just stay away.
Paradoxically, due to the positive feedback loop of people downvoting comments that they disagree with and thereby driving away dissenting voices, comment threads on polarizing topics like these tend to be a pretty poor representation of actual popular opinion, as opposed to the opinion of the loudest people in the room.
What I absolutely LOVE is a much more robust ordering of system service turn ons. Start network BEFORE ntpd. Start rpcbind BEFORE nfs-server. A lot of hack solutions for this chicken & egg problem in the past were always very fragile.
The point is that, if you're thinking of it as a linear ordered sequence, you have the wrong mental model. On the other hand, systems like OpenRC do work that way.
Are you sure that OpenRC works in this way?
There may be some subtlety that I'm missing, but the documentation for systemd unit files [0] seems to describe a service dependency and ordering specification system that looks equivalent to what OpenRC provides with "need", "use", "before", and "after". (Search for "[Unit] Section Options" and read on from there.)
[0] http://www.freedesktop.org/software/systemd/man/systemd.unit...
Simplifying things, your unit file actually becomes a Unit object which queues a job (which is itself a Unit) which is scheduled and checked for consistency in a transaction, which encapsulates a service (itself a Unit and one that controls jobs). The final graph of dependency information largely does not reflect what you configured.
Ah. That would be the "subtlety" that I was missing. Thanks! :)
As an aside: how terrible it is to provide an interface that makes it look it gives you ordering guarantees when -in actuality- it gives you no such thing! :(
Logrotate solves this for me, for every logging method. How did it fail for you?
> ...no more minute-long boot delays...
I don't have this issue with OpenRC on Gentoo. shrug I do know that Kubuntu 15.04's boot time is irregularly slow, and that its shutdown process -every once in a while- hangs forever, requiring the use of SysRq keys. This didn't happen with the previous, Upstart-based version of Kubuntu. (Then again, there are many things wrong with Kubuntu 15.04, so this might not be entirely systemd's fault. ;) )
> ...no more debugging undocumented shell scripts for booting...
Scripts written for OpenRC are typically easy to read. Complex tasks -necessarily- require complex scripts, but you'd have to write and call out to those scripts with systemd, too!
> ...no more writing init scripts...
For services whose startup is as simple as what systemd handles out of the box, I can write a one-to-seven-line startup script for OpenRC and call it a day. Additionally every service packaged in my package manager has come with a init script. [0]
> ...no more brittle, half-assed distribution-specific networking solutions...
shrug Gentoo uses netifrc. It does appear that this is a distro-specific way to bring up the network, [1] but I assure you that it's full-assed, has a well documented and flexible config file, and is not brittle.
[0] Some of them -like the network startup scripts, and the OpenVPN startup scripts- let you make a symlink to the original script, which changes the behavior of the script.
In the case of the network startup scripts, this makes that script change the state of a particular network interface, virtual or otherwise.
In the case of OpenVPN's script, this causes the startup script to look for config files with a different name. In the OpenVPN case, you symlink /etc/init.d/openvpn to /etc/init.d/openvpn.newconfig . The symlinked openvpn startup script then uses the OpenVPN config file /etc/openvpn/newconfig.config to start the "openvpn.newconfig" service. It's really handy!
How would you do this in systemd? Make a new unit file?
[1] Only because -like all distro-specific things-, noone else has bothered to adopt it. ;)
systemd start openvpn@<config_name>
[0] http://www.freedesktop.org/software/systemd/man/systemd.unit...
You're mistaking people's dislike for systemd with a love of sysv init - no-one liked sysv init and everyone wanted a change. It's just that systemd has taken a very broad remit, plus the maintainers have a 'fuck your use-case' attitude.
But systemd is not only an init daemon anymore and the systemd developers work actively to cut off everything that is not systemd (see the udev saga as an example) or make idiotic decisions (NTP server defaults?). And that, in addition to some other things (why should udev be part of systemd? Why should be there an arbitrary limitation in core files size? See also [1] for more) left me very worried. And I don't like journald at all, rsyslog does almost everything already.
And the way Fedora integrated kdbus before it was put into the mainline kernel? That's ridiculous, sorry.
The need to make another 'su' because the older one was not good enough in the mind of the developers?
And now 'systemctl is-system-running'? Wat?
http://www.landley.net/notes-2015.html#05-07-2015 is a lovely entry from Rob Landley about trying to maintain an alternative to udev, and getting the runaround by GregKH and Kay Sievers.
> or make idiotic decisions (NTP server defaults?).
Love the excuse for that. "Systemd is not meant for end users, and distros should set their own servers anyways".
Its like anyone thats not a developers working for/on the large name distros are users (aka consumers, aka mooo) and should shut up and accept what the distros ship.
Most arguments against sysyemd appear to be appeals to tradition, not based on any technical deficiency. In actual use I have found no fault with it and it does make some things easier.
The only argument against sysyemd that I find somewhat sympathetic is the fact that there is always a cost to pay when migrating to and learning about something new. This is certainly true. However, I find the user experience of systemd to be superior, and this small upfront price seems worth paying.