systemd: system doubts
My new workhorse laptop (running Ubuntu Linux) had disturbing symptoms. Never have I had to use the power button so often to shut down a Linux box. Mystery. Linux traditionally has been a bedrock of stability. It took me a while to realize that a handful of problems point in the same direction: systemd.
Sometimes when I got back to my suspended system there was a dialog on the screen saying “Authentication required to suspend”. What, are you kidding? Sometimes I had to unlock the system twice after suspend. I noticed that if, after suspending, I happened to touch the wireless mouse or keyboard, the system would fire up even though the lid was closed. Now and then it would flatly refuse to shut down. I never use reboot because it failed so many times.
Then there was a seemingly unrelated problem, cron did not start at boot. It’s such a basic thing, cron has been there since times eternal. I’m a developer, not a kernel person, but I expected 5 minutes of Internet browsing would bring me a solution.
I found a lot, but every piece of advice began: it depends. Is your box Upstart or systemd? Uh well, that was not my focus area. It turned out my box is systemd. At first I thought, well, let’s get it done. I plunged into a search for documentation and emerged a good while later with an unexpected conclusion:
systemd gives me doubts. Its scope is so all-encompassing that one could say it defines its own galaxy. But it lacks a user interface. Users in this case are people setting up or managing a Linux system.
- There is no reliable way to tell if a box is managed by systemd. StackExchange has a number of suggestions. Each with a warning that it may fail.
- Documentation is scarce. The user is encouraged to read man pages. systemd consists of 69 modules, each with a man page, just go ahead. The web site has a FAQ with some weird questions. The most basic and obvious one, how do I make a service start on reboot, is not there. There is a lengthy document stating 30 things systemd is not. My need is exactly the opposite.
- And there is really no user interface in the conventional sense of the word. systemd faces the computer. Users just see the back turned against them. And it makes me of think of the back of a wire-wrap board, if you remember them.
The analysis that prompted the creation of systemd seems correct (I’m not an expert). A paradigm shift is needed. And journald is a wonderful idea. However, correctness does not guarantee usability. If you don’t believe me, check out SGML for a big time example. It was provably correct, but also terrible to use. It was promoted as a technology of the future, but is now all but forgotten, overtaken by its poor cousin XML.
The scarcity of documentation worries me. A design is debugged by writing user documentation. If you can’t explain something in a few words, that’s how you discover bad design. Abstractions are the key.
I wish systemd had layers. I wish there was a layer with abstractions for the casual user. There are certainly users who need to operate the whole mess. But it should not be necessary to spend hours to discover the 1-2-3 operation of introducing a custom service to be started at boot.
By the way, the reason cron does not start is that there is no unit, in the systemd sense, that depends on cron. Since systemd finds that no one depends on cron it doesn’t start it. To cure the problem, enable the cron service. Or create a new unit that depends on cron. (But then that unit has to be started at boot…)
Ok, I may be wrong. Just hit me on the head and I’ll learn something.