Back in 2014, I wrote about some negative first impressions of systemd. I also had a plea to debian-project to end all the flaming, pointing out that “jessie will still boot”, noting that my preference was for sysvinit but things are what they are and it wasn’t that big of a deal.
Although I still have serious misgivings about the systemd upstream’s attitude, I’ve got to say I find the system rather refreshing and useful in practice.
Here’s an example. I was debugging the boot on a server recently. It mounts a bunch of NFS filesystems and runs a third-party daemon that is started from an old-style /etc/init.d script.
We had a situation where the NFS filesystems the daemon required didn’t mount on boot. The daemon then was started, and unfortunately it basically does a mkdir -p on startup. So it started running and processing requests with negative results.
So there were two questions: why did the NFS filesystems fail to start, and how could we make sure the daemon wouldn’t start without them mounted? For the first, journalctl -xb was immensely helpful. It logged the status of each individual mount, and it turned out that it looked like a modprobe or kernel race condition when a bunch of NFS mounts were kicked off in parallel and all tried to load the nfsv4 module at the same time. That was easy enough to work around by adding nfsv4 to /etc/modules. Now for the other question: refusing to start the daemon if the filesystems weren’t there.
With systemd, this was actually trivial. I created /etc/systemd/system/mydaemon.service.requires (I’ll call the service “mydaemon” here), and in it I created a symlink to /lib/systemd/system/remote-fs.target. Then systemctl daemon-reload, and boom, done. systemctl list-dependencies mydaemon will even show the the dependency tree, color-coded status of each item on it, and will actually show every single filesystem that remote-fs requires and the status of it in one command. Super handy.
In a non-systemd environment, I’d probably be modifying the init script and doing a bunch of manual scripting to check the filesystems. Here, one symlink and one command did it, and I get tools to inspect the status of the mydaemon prerequisites for free.
I’ve got to say, as someone that has occasionally had to troubleshoot boot ordering and update-rc.d symlink hell, troubleshooting this stuff in systemd is considerably easier and the toolset is more powerful. Yes, it has its set of poorly-documented complexity, but then so did sysvinit.
I never thought the “world is falling” folks were right, but by now I can be counted among those that feels like systemd has matured to the point where it truly is superior to sysvinit. Yes, in 2014 it had some bugs, but by here in 2016 it looks pretty darn good and I feel like Debian’s decision has been validated through my actual experience with it.
I’m not a sys admin, but I use Linux Mint on my laptop. So my perspective is as an ordinary individual user. A while back I had an issue on my laptop that required digging around in the init system. Because I am not an admin who works with it every day, figuring out where the problem was was practically impossible and I ended up just doing a reinstall of the OS (and I realize that is usually not an option for server admins). So I could appreciate the development of systemd. My main concern was the reports that systemd was not really ready for primetime, as it were, and on the whole I am glad that the Mint developers took the more cautious route and postponed implementing it until it could be developed further.
I agree, same case of changing mind here.
Requires=remote-fs.target is wrong for your daemon, you need to set After=remote-fs.target.
Your mounts order themselves as Before=remote-fs.target
It was already doing it after remote-fs.target due to inferences from the LSB headers in the init script. The problem was it was missing Requires.
Odd that the init script wasn’t written to check for required mounted file systems. Not as if checking that expected mounted file systems WERE actually mounted hasn’t been an issue for decades.
As a side note you shouldn’t be manually doing symlinks like this but instead express it within your systemd unit with an appropriate requires and/or after as appropriate…
Also if dealing with services requiring mounts you may want to check out the directive RequiresMountFor instead which will ensure the specific mounts are there and not start the service without them, assuming you know what the mount paths will be rather than a generic “after remote-fs is complete please” entry.
Few days I ago I put (again) VoidLinux on my netbook and plan to migrate my desktop as well – both were running Debian Sid – and I am happy that Void uses runit – pure simplicity to handle services…yes, it works with GNOME3. ;)
I will keep using scripted init systems (currently using voidlinux and jessie/sid, with an eye on guix and crux) instead.
Because I am comfortable with the solution you do not prefer, to fix your problem all you need is knowing some bash and what mount does. Such knowledge, if not already present, once acquired will be useful to normal use of your system.
Whereas the systemd specific commands have only one possible application.
Different strokes for different folks I guess.
I am going to continue to swing a hammer around my apartment trying to kill flies, because knowing his to precisely swing a hammer is useful in many circumstances, whereas a flyswatter is only useful in one.
My biggest complaint about systemd is it still breaks what I consider reasonable sysadmin workflows. For example, on my servers with NFS-mounted home directories, I can no longer do “sudo reboot”; the system will hang indefinitely during shutdown and require a hard reset. With systemd it’s necessary to directly log in as root in order to do a remote reboot, which is unfortunate because I prefer not to allow root ssh logins.
Is the anti-systemd group being lulled into complacency by ease of use? The fight as I saw it was about the size of systemd, its reach into the system which would undoubtedly create new attack vectors, and the violation of the old UNIX adage of do one thing and do it well. Seems like those arguments still survive despite ease of use. I’ve seen many articles similar to this one from recent systemd converts. Were the other concerns just straw-men for folks that didn’t want to change?
Even though the systemd change makes sense, if nothing more than pushing the init system to evolve, I think the anti crowd had some fair points that were worth being discussed and incorporated somehow.
Wow. Just realized how much it’s like the US political process. :-)