4 ms·

I guess I did not explain myself properly, s6 is not actually a wrapper over sysvinit in practice, it's its own thing, like runit. But like runit it relies on b

I guess I did not explain myself properly, s6 is not actually a wrapper over sysvinit in practice, it's its own thing, like runit. But like runit it relies on bash scripts, which are not declarative and open to a wide variety in quality, just like with sysvinit. Also, runit does i.e rely on logind, which everybody forgets systemd took upon themselves as consolekit was unmaintained. Why does runit rely on systemd's work here? > runit shuts things down properly; with systemd I often have to literally 'yank the cord' I've looked at how systemd handles shutting things down vs other inits and it's just a lot more paranoid, i.e. it waits for confirmation of every single service being shut down etc. In other init systems it tends to be a case of 'send shutdown signal, assume process shuts down'. You could fault systemd for this, but it's more of an application-level issue.

_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 ago
    But 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 ago
      I 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 ago
        It 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.

_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 ago
  But 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 ago
    I 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 ago
      It 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.