[throw7]

Lennart came down from heaven (or, depending on your perspective, up from hell) and looked at the state of linux distributions.

He said, "This sucks. Boot times are slow. Distros have a mish-mash of init systems and shell scripts, all subtlety different. Linux features like cgroups, which are the bee's knees, are left as an exercise to the sysadmin. Why aren't user processes manageable? etc."

Thus systemd decided it was going to standardize a new layer between the linux kernel and userspace using a declarative model for configuration for... like everything. This was a huge change in the linux world. A huge change was going to be controversial. Systemd is still controversial.

Systemd won though.

[throwaway0x7E6]

>He said, "This sucks. Boot times are slow

https://www.google.com/search?q=a+start+job+is+running+for

[nousermane]

If only they paid equal attention to shutdown as well. It is relatively easy to inadvertently break a systemd install in such a way that reboot/shutdown would go through a number of grotesque "tasks" with very generous time-outs:

- Unmounting filesystem /mnt/nfs (X seconds out of 1:30)

- Waiting for D-Bus to terminate (Y seconds out of 4:00)

...and so forth. It's so bad, there is a special "C+A+D, 7 times in two seconds" key combination to deal with those. Which, I've seen fail as well.

[creeble]

+10 on this. The first thing I noticed years ago from running a systemd-based distro, is that shutdown (thus reboot) got stuck in "...waiting for xxx to terminate" for multiple minutes. This had never happened before, and there were never consequences from it not happening. So it was (and remains, in many hard-to-debug cases) strictly a drawback for systemd-based systems.

[codedokode]

It could be a bug in a third party service that didn't shut down properly or wasn't integrated with systemd properly. You should not put a blame on systemd without investagating first.

[orf]

Sorry, what does that link have to do with anything?

[throwaway0x7E6]

with systemd, boot/shutdown time has a chance to be indefinite

[vetinari]

> declarative model for configuration for... like everything.

Here I find that many people look for the wrong thing. Their idea is 'do $stuff at boot'.

However, systemd does 'do $stuff at $event', where 'boot' is one of the events in the set. They are not wrong though, we are used to cron is not a valid reason why it should not get unified.

[deathanatos]

… but you can still just run your favorite crond, and keep doing exactly what you were before? I've still never run a cron job under systemd, and I've never hit trouble doing that. I.e., Systemd doesn't force you to use it for cron.

Although, now that I'm looking at ArchWiki's "list of reasons you might want to do this" … it checks off basically every problem with traditional cron. I might need to start using this.