Slashdot Mirror
Ask Slashdot: Can You Say Something Nice About Systemd?
ewhac writes: "I'm probably going to deeply deeply regret this, but every time a story appears here mentioning systemd, a 700-comment thread of back-and-forth bickering breaks out which is about as informative as an old Bud Light commercial, and I don't really learn anything new about the subject. My gut reaction to systemd is (currently) a negative one, and it's very easy to find screeds decrying systemd on the net. However, said screeds haven't been enough to prevent its adoption by several distros, which leads me to suspect that maybe there's something worthwhile there that I haven't discovered yet. So I thought it might be instructive to turn the question around and ask the membership about what makes systemd good. However, before you stab at the "Post" button, there are some rules...
Bias Disclosure: I currently dislike systemd because — without diving very deeply into the documentation, mind — it looks and feels like a poorly-described, gigantic mess I know nothing about that seeks to replace other poorly-described, smaller messes which I know a little bit about. So you will be arguing in that environment."
Nice Things About systemd Rules:
Bias Disclosure: I currently dislike systemd because — without diving very deeply into the documentation, mind — it looks and feels like a poorly-described, gigantic mess I know nothing about that seeks to replace other poorly-described, smaller messes which I know a little bit about. So you will be arguing in that environment."
Nice Things About systemd Rules:
- Post each new Nice Thing as a new post, not as a reply to another post. This will let visitors skim the base level of comments for things that interest them, rather than have to dive through a fractally expanding tree of comments looking for things to support/oppose. It will also make it easier to follow the next rule:
- Avoid duplication; read the entire base-level of comments before adding a new Nice Thing. Someone may already have mentioned your Nice Thing. Add your support/opposition to that Nice Thing there, rather than as a new post.
- Only one concrete Nice Thing about systemd per base-level post. Keep the post focused on a single Nice Thing systemd does. If you know of multiple distinct things, write multiple distinct posts.
- Describe the Nice Thing in some detail. Don't assume, for example, that merely saying "Supports Linux cgroups" will be immediately persuasive.
- Describe how the Nice Thing is better than existing, less controversial solutions. systemd is allegedly better at some things than sysvinit or upstart or inetd. Why? Why is the Nice Thing possible in systemd, and impossible (or extremely difficult) with anything else? (In some cases, the Nice Thing will be a completely new thing that's never existed before; describe why it's good thing.)
We will assume out of the gate that systemd boots your system faster than ${SOMETHING_ELSE}, so no points for bringing that up. Bonus points are awarded for:
- Personal Experience. "I actually did this," counts for way more than, "The docs claim you can do this."
- Working Examples. Corollary to the above — if you did a Nice Thing with systemd, consider also posting the code/script/service file you wrote to accomplish it.
- Links to Supporting Documentation. If you leveraged a Nice Thing, furnish a link to the docs you used that describe the Nice Thing and its usage.
Using the information gleaned from this year old bug I was able to create a Tower of Hanoi solver using the dependency resolver's attempts to determine whether a NFS filesystem should be mounted after the network comes up or not. Every attempt to start Apache (which depended on the filesystem) represents moving a disc to the middle tower.
Are you trying to imply that all the hatred I've heard about pulseaudio was also unjustified?
Only if you have a setup like Potterings, since he rewrote the pulseaudio configuration to work on his computer and just deleted features he wasn't using to "keep it easy".
Sort of like how if you're using systemd in an NFS world you're going to have a bad day, since he still hasn't made their dependency resolution work correctly with networked filesystems. Funny that rc dealt with that ages ago by having S01mount S05network S10networkmount but I'm sure there's a very good reason systemd is incapable of using mount -a -t nfs,cifs,smb,afs,etc, I suppose we'll need the kernel rewritten to support a systemd-mount program to solve this problem, which will of course be incompatible with standard mount.
Just installing systemd over sysv speed booting up from a minute to 10 seconds, and shutting down from half a minute to under one second. I always hated Linux couldn't handle shutting the fuck down efficiently, now it does.
Wait, what? It's the other way around. If the dependencies are systemd managed, systemd will wait until they report back to be up and running before starting dependants. This is opposed to the SysV rc way, which just blithely ignores all output and continues booting unless the rc script actually hangs.
In fact, one of the most common complaints is that systemd keeps hanging on filesystems in fstab that are not mandatory to mount on boot, instead of ignoring the mount error and leaving them to be mounted manually later.
"I know I will be modded down for this": where's the option '-1, Asking for it'?
Back in 1993 I worked on a network process controller for Inmarsat-A. It had it's own custom init process group leader which erected unix domain IPCs between certain children, some shared memory segments, and performed a waitpid to relaunch any child process that died. I was new to the project and new to unix so when I suggested we use inittab to take over this task, the team lead just laughed. Init was not up to the task. The arrival of systemd finally addresses this use case: a process group leader that can care for of a hierarchy of tightly coupled processes. Systemd may be complicated, but so is the intended use case.
In which case a nanny process restart is useless. Thanks for making my point, idiot.
Your logic is flawed. Random bit flips sometimes happen. They don't necessarily take down the whole machine.
OK I'll try this. Traditionally Init services were about starting processes. They didn't have capacities for keeping processes running. Which meant that for processes that need to be kept running and for which there was a real possibility of failure (most of them) the init had to start a process management system which then started the functional process. This has been the status for years. With systemd there is a process maintenance component standard in the init system. Which means that processes not only start but are capable of being kept in a stable state easily and automatically. Process management stops being something system admins work hard at and instead becomes something that happens out of the box.
Funny that rc dealt with that ages ago by having S01mount S05network S10networkmount but I'm sure there's a very good reason systemd is incapable of using mount -a -t nfs,cifs,smb,afs,etc,
Really? I confess I haven't looked at how to configure systemd much, but from what I have seen, that sort of setup could be supported easily enough by writing the right unit files (or whatever they're called) and specifying the dependencies.
Yes, exactly. So, by developing a clear understanding of systemd syntax and dependency specification, you should be able to solve the dependency problem that rc/sysvinit solved fifteen years ago by specifying that dependent processes start after their requirements.
This is actually a silly example. If all of the start-up processes are loaded sequentially, then order is really not a hard thing to sort out. You can do it manually, in your head, and your brain can process what's going to happen. Systemd introduces a massive complication by allowing init processes to happen in parallel. So, now you've got this horrible optimization to do, where you separate all of the separate init processes into mutually independent sequences that start in parallel. So, your brain can tell that you should start network file systems only after you've started the network, but how about the audio driver? Can you start named in one process while starting apache in another?
My point is that the dependency issue is really something that systemd introduces, and the benefit of its automatic dependency resolution is only relevant in the context of systemd. If it's really important to you that your computer be able to start multiple daemons in parallel, rather than wait the 5 seconds it takes to start bind before starting apache or samba or whatever, then systemd does that and solves the problems it introduces. If you'd rather understand what happens as your system starts up and not trust someone else's optimization, then systemd is not for you.
We've had problems a few times with systemd (usually the next boot after an upgrade to a package). Without exception, the failed boot occured with next-to-no meaningful error on the console and was more difficult to debug than if it had been using sysvinit. I personally, as a sysadmin for ~16 years, don't see a problem with sysvinit that justifies tearing it out of Linux for a more complicated, more opaque replacement.
I came here to post something similar. We've seen a load of switchers over in FreeBSD land as a result of systemd, including one company that's currently a moderately large RedHat customer and plans to migrate before their current support contract expires.
I am TheRaven on Soylent News