See, this right here is the (technical, not social) problem with systemd. Whether anyone points out that systemd is doing something stupid and wrong, the systemd shills' answer is always "well duh what did you expect when you didn't modify one of the hundred default configuration files to have `[stupidshit] = false`! You brought this on yourself!" And you're lucky if that even works to solve the problem.

What's stupid or broken in waiting for a service to shutdown?

I mean Slackware used to send a SIGTERM to all processes, wait two seconds, and send a SIGKILL. Why would anyone need more? It's the Unix way (except it isn't).

If you disagree with the default wait time then you disagree with the default wait time. So what.

On this particular issue I find it hard to fault them for using a (perhaps overly) safe default.

Summarily killing processes with a SIGKILL should really be a last resort because it can very easily corrupt data.

If you have processes which just hang for ages during shutdown, there is probably something wrong with your system (or the process's code) which might warrant further investigation.

If your software corrupts data when it's killed, it's honestly not very good software.

I kinda wish "proper shutdown" was never invented at all. That would've motivated so many developers to care about reliability much more :P

I don't disagree, necessarily, but ACID[0] is/was quite expensive for (usually) marginal gain. These days, I'm sure it could be done a lot more efficiently (with SSDs and such), but the fact is that there's no real way to do it using just POSIX syscalls. Applications literally cannot 'signal' transaction boundaries wrt. file system writes as it is. The APIs simply aren't there.

[0] Well, not exactly, but you get the idea.

Flash wear and disk write ack latency would shoot up the roof for that to work unfortunately.

Only if you care deeply about always having the latest data, rather than just consistent data.

I'm talking more along the lines of ZFS – I can always pull the plug without worrying about FS consistency, because the FS always goes between valid, consistent states atomically.

What about having for example libreoffice running with unsaved changes? (And I know it does backups regularly but not after every character)

Current generation file systems, including ext4, already have journaling to prevent this.

True, and you can even turn data journaling on. The problem is... what is an "atomic write" from the perspective of an application? There is no POSIX interface for that. Of course making a single 'write()' syscall atomic, and so forth is a good thing, but... that's not an application level 'transaction' necessarily. Libc has buffering between fwrite and write... that's pretty arbitrary (fflush notwithstanding). Also: Dirty read (A) -> Writes that are committed, but the data read (A) doesn't get committed. Uh, oh!

The problem is a thorough lack of semantics on file systems. It's the wild west.

ACID was a good start for databses, but even that is pretty vendor specific in the specifis... and nobody truly understands the basics of it anyway.

It's a difficult problem.

/me shrugs

It's just another init system to me. I don't really care enough about it to get upset and complain that I had to read some documentation and edit a text file to change its behavior.