> The default journalctl should show where things have failed

How? What do you filter for? Emergency? Critical? Error? Alert? (see `dmesg -l`). What's the default? Do you do since boot? Since a certain time? Since restart?

FWIW, I invoke it all the time for other reasons. I am legitimately checking the status. Is it online? Do I have it enabled? What's the PID? Where's the file (though I can run `sudo systemctl edit foo.service`)? What's the memory usage? When did it start? And so on. The tail of the log are useful but not the point of status.

If I'm looking to debug a service I look at the journal instead. I hope this helps

# Show 10 most recent logs (you don't know what service to debug)
journalctl -r -n 10
# Show recent logs for a known service (can tab complete)
journalctl -r -n 10 --unit foo.service
# Some useful flags
-S, -U
Since and until. Time filtering including keywords {now, yesterday, today, tomorrow}
-b
Since boot. You can even do since a specific boot! Or even `--boot=-1` for the last 2 boots
-p, --priority
You can use the numbers 0-7 representing {emerg,alert,crit,err,warning,notice,info,debug} respectively
-g, --grep
No comment needed
-f, --follow
This is the tool while debugging since it'll update.
-e, --pager-end
Start at the end of the pager

> that's why people are invoking it.

That's why __you're__ using it, but don't assume that your usecase is the general. Remember, linux has a large breadth in types of users. But their biggest market is still servers and embedded systems. There's far more of those than PC users.

> Choices were made to be hostile to usability and they continue to be defended by being hostile to usability.

Idk, when systemd became the main thing I hated it too. But mostly because it was different and I didn't know how to use it. But then I learned and you know what? I agreed. This took awhile though and I had to see the problems they are solving. Otherwise it looks really bloaty and confusing. Like why have things like nspawn? Why use systemd jobs instead of using cron? Why use systemd-homed instead of useradd?

Well a big part of it is security and flexibility.

I write systemd services now instead of cron jobs. With a cron job I can't make private tmps[0]. Cron won't run a job if the computer is off during the job time. Cron can't stagger services. Cron can't wait for other services first. Cron can't be given limited CPU, memory, or other resource limitations.

Nspawn exists to make things highly portable. Chroot on steroids is used for a reason. Being able to containerize things, placing specific capabilities and all that. This is all part of a systemd job anyways. It really makes it a lot easier to give a job the minimum privileges. So often nspawn is a better fit than things like docker.

Same goes for homed. You can do things like setting timezones unique to users. But there's so much more like how it can better handle encryption. And you can do really cool things like move your home directory from one machine to another. This might seem like a non-issue to most people but it isn't. That whole paradigm where your keyboard is just an interface to a machine (i.e. a terminal, and I don't mean the cli. There's a reason that's called a terminal "emulator"). This is a really useful thing when you work on servers.

Look, there's a reason the distros switched over. It's not collective madness.

[0] https://www.redhat.com/en/blog/new-red-hat-enterprise-linux-...

https://systemd.io/