[ilyt]

I despise the amount of random stuff that's tied to it and journalctl data format is still an abomination (and my bug with it trying to search thru entirety of log dir to show single app status is still open)

...but we did remove few thousands lines of fixed init scripts (anyone that tells you sysv scripts are easy and simple is lying to you, multiple projects fail there) *and* an bunch of Monit instances thanks to the features the base service management has. And simplified a bunch of other cases.

So yeah, overall even with issues it is a huge benefit.

[necrotic_comp]

The process control in systemd I think is unambigously good, but it would be nice if it wasn't as tightly coupled with journalctl and all of the other random stuff it's gobbling up.

[ilyt]

Well, to be fair you can't exactly ask typical syslog demon "give me log files of an app" but the way journalctl implemented it is just fucking terrible.

It takes 4 whole seconds [1] for systemctl/journald to tell me it has no logs for the daemon on my NAS and it opens 985 files while it is doing it

If it just used sqlite as a backend it might've been useful for analysis (on top of way faster...) but Lennart wanted to have a go at implementing binary DB format badly so we're stuck with it.

If it at least kept a pointer to last file the app's logs were written to the lack of proper indexing also wouldn't be a problem.

But nope, it's just entirely worse than text format. And I do mean that in entirety, acking thru text files is faster than systemctl trying to find log files for the app...

* [1] https://github.com/systemd/systemd/issues/2460

[taskforcegemini]

My favorite experience with journalctl from many years ago was when an application kept spamming the logs till there was no space left. Once that point was reached, the binary logs got corrupted so couldn't be opened to investigate the cause. Don't remember how many turns it took me.