3 ms·
> But like runit it relies on bash scripts, which are not declarative and open to a wide variety in quality, just like with sysvinit. In theory, this makes sen
by _emacsomancer_ 7y ago
> But like runit it relies on bash scripts, which are not declarative and open to a wide variety in quality, just like with sysvinit.
In theory, this makes sense, with potential issues of poorly written shell scripts. In practice (I assume arising from its increasingly baroque growing complexity) systemd ends up with stability issues which aren't pleasant from an end-user perspective.
Setting shutdown aside, I had a horribly difficult-to-debug boot issue with systemd: a daemon failing in an unexpected way caused a failure to bring up any services, but without systemd failure messages. The problem was a systemd emacs service. On one boot I had an issue in init.el which caused emacs initialisation to hang, so the root cause wasn't systemd. But systemd didn't fail gracefully (or informatively) in this case. And it took me a while to figure out why systemd wouldn't bring up any services, since it wasn't reporting to me that the emacs service (or any service) had failed.
I've since reverted to launching emacs daemons via .xinitrc or the like on my systemd boxes, so that any emacs init issues don't pull the rest of systemd down.
- acdha 7y ago> On one boot I had an issue in init.el which caused emacs initialisation to hang, so the root cause wasn't systemd. But systemd didn't fail gracefully (or informatively) in this case. And it took me a while to figure out why systemd wouldn't bring up any services, since it wasn't reporting to me that the emacs service (or any service) had failed If it’s hanging it hasn’t failed. If that daemon is configured as a blocking dependency, waiting is the correct thing to do — this is why timeouts and health-checks are as important as making sure that your dependencies are as flat as possible.
- _emacsomancer_ 7y agoBut as far as I can tell, the Emacs daemon shouldn't be a blocking dependency. Here's the systemd unit definition I would have been using at the time: https://wiki.archlinux.org/index.php?title=Emacs&oldid=469589#As_a_systemd_unit https://wiki.archlinux.org/index.php?title=Emacs&oldid=46958... . And here's a more recent one: https://wiki.archlinux.org/index.php/Emacs#As_a_systemd_unit https://wiki.archlinux.org/index.php/Emacs#As_a_systemd_unit . Neither of these should be blocking dependencies, should they? `WantedBy=default.target` doesn't make it blocking, does it? Is there something more that should be added to these sorts of unit definitions to improve graceful failure scenarios in systemd?
- PlutoIsAPlanet 7y agoI think it might, this really just sounds like a misconfigured unit. in which case systemd is doing exactly as it's told. Edit: That linked unit is for user level systemd, so it shouldn't be involved in the system boot at all.
- _emacsomancer_ 7y agoIt definitely is/was a user-level unit, which makes it unclear to me why it should have interfered with bringing up other services in general.