> Do you mean openRC, s6 etc? They still all use bash scripts, (which as a result depend on the dev for quality and can vary quite a bit) vs systemd's clear, uniform service definitions. They don't provide much beyond starting services and are more like wrappers around sysvinit than anything else.

I'm not that familiar with openRC or s6 (I've played with them, but don't use them on any 'real work' systems), though my understanding is that there is a proper openrc-init being developed.

I was actually thinking more of runit and shepherd, which provide their own init and daemon-management.

> > my runit systems all behave themselves; my systemd systems frequently hang on reboot

> Every time I've seen this in practice it turned out the system was actually not configured properly, (usually crypttab or something related),

This is across multiple systems, from Arch boxes, which I've hand-configured to vanilla Ubuntu boxes, and ranges in behaviour from multiple 90s timers to just hanging on completely black screen until forced to reboot. There are certainly no obvious configuration issues on any these, definitely not crypttab or the like.

> shut down properly vs other init systems just yank the cord, but it seems faster, so I guess it's 'better', (in which case you can just shorten the systemd timer to like 1s and it would be even faster doing that)

But, even timers aside, runit is faster than systemd on both boot and shutdown, for similarly-configured systems. And provides (me at least) a best user-experience than systemd.

runit shuts things down properly; with systemd I often have to literally 'yank the cord'.

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.

> 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.

> 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.

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=46958... . And here's a more recent one: 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?

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.

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.

if your systemd isn't able to "shut things down" quickly, that's the fault of an application not responding to a shutdown signal and systemd waiting before it kills it.

For the timer-issues, perhaps. But that doesn't cover the completely black screen hangs.

s6 is often used with execline, a stripped down scripting language that is highly performant.