Another systemd rant —
Systemd seems to take control away from the console user. For instance, with Sysvinit, if I encountered a problem with a startup or shutdown script I could normally CTRL+C out of it and the system will continue on its merry way.
Today, I shut my computer down to air-dust it. When I hooked it back up and turned it on, it quickly mentioned about having to run fsck and then gave some other (normal) errors about my video adapter. From here, it simply sat there with no indication that it was doing anything. After about 3 hours (my wife and I went outside to wash and wax our cars), it was still sitting right there, with no additional log output to the console. So much for early-boot-logging, if you can’t view anything, right? I was completely in the dark as to whether or not the system just plain locked up. I hit CTRL+ALT+DEL, and the system started running toward the shutdown goalpost, and then somehow locked up doing that as well. I had to hit my ATX reset button. Luckily, the next boot went all the way in.
I can’t help but feel the same “locked out” feeling from my own console that I used to feel with MS-DOS. It’s a peculiar feeling, really. When I first started using Linux, I was weirded out by how you could hit <Enter> during almost anything on the console and it would carriage return. I felt like using tools like more, less, grep, etc. was like swimming in the middle of a lake, kicking fish around underneath me. Hard to explain, really. BUT, I got used to it. Very used to it. I felt then that I was in total control of my system, being able to break out of almost anything, pass commands via bash or busybox, because PID 1 was essentially a skeleton that allowed each bone to do its job on its own. If one bone failed, you still had the whole rest of the skeleton to keep the body upright. SystemD is like the T-1000. It may be ultra hardcore, but throw a little liquid nitrogen at it and hit it with a slug and watch the whole thing shatter into little tiny pieces.
Another qualm I have is that, due to the parallel nature of how startup items get processed, and this might just be my own taste, but when I log into X, other things in the background are still starting up, making my graphical login experience much more like…should I even say it? Windows. There. I said it.
Seriously. If I wanted my login to be hampered by other shit loading in the background, I would be paying out of my pocket for an M$ OS license. I think there is a very good reason for at least waiting for things to load before allowing a graphical login, for aesthetics sake. With sysvinit, I mean, one thing at a time, right? The greeter is last…so the system is lightning fast by the time you log in. I really don’t give a shit about fast bootup times – one of the reasons I use Linux is that I hardly ever reboot. Uptime is bragging rights. Systemd’s position is apparently that reboots are frequent. That’s just plain sad, really.
Systemd doesn’t currently give the proper tools (at least as far as I know – someone prove me wrong?) to deal with hung jobs (such as one time I encountered smbd having to wait up to 5 minutes to shut itself down, with no option for me, the administrator, to alter it at that point in time..I had to sit there like a fool and wait. It was like being stuck at a red light that won’t change). It assumes it is smart enough to handle unpredictability with its children, but at least for right now, it is the parent who thinks it knows everything. Thinks.
I am hopeful, however. I do believe in the project, as long as it is a fair and open process (no pun intended).
Categorised as: Blogs | Technical
That last point you brought up is actually what concerns me the most. All the other stuff can be mitigated (and I’ve had to, despite the “it just works… just let systemd handle it” rhetoric. More like “it just breaks it” or “it just sigints your service’s processes every time instead of gracefully shutting it down” in one case.)
Another *strongly* related point is, why can’t it be broken down into smaller pieces? Can’t there be a systemd service manager on its own? I wouldn’t mind a new service manager if it worked (well). Why does it have to utilize the “one ring” leadership strategy? It seems like every command has become systemctl this or systemctl that. It doesn’t have to be all or nothing.
It also appears on the surface like it’s basically one guy pushing his centralization of everything and for some reason all of the distros are falling all over it? Because they need a faster/better service manager? I don’t buy that story. Something is fishy about the whole thing.
But I suppose these things have to happen from time to time to test the OSS community’s resolve and determination.
There is no spoon, but will there be forks?
Excellent points. The whole feeling that Pottering seems to not understand is that he is being very naive about his software’s maturity. You can’t get much more crucial with a system than taking the role of PID 1. His track record for introducing software into distros isn’t exactly something that sits well with me when talking about blindly accepting systemd (and no other option, at that) as my computers’ default init manager. I have personal issues with Ubuntu’s early adoption of PulseAudio in an LTS release as I had to deal with it in LTSP environments, and it was horribly broken.. I literally spent weeks researching, testing patched packages from PPAs and using undocumented configurations just so thin clients could hear sound…it was the same situation. It was, ‘Tough luck, this is what we’re doing, it’ll be solid by next release, blah blah blah’.
I am as surprised as you that so many of the major distros seemingly fall in love with whatever projects he starts, even though they haven’t been thouroughly tested. To me, he sounds like Mark Shuttleworth’s kid, or something. They both put their blinders on because they think they don’t have to pay attention to the ones that oppose their ideas.