←back to thread

466 points CoolCold | 2 comments | | HN request time: 0.62s | source
Show context
kbar13 ◴[] No.40208219[source]
systemd has been a net positive for the linux ecosystem. remember when you had to write bash scripts to start, stop, restart services and handle any other signals you want to send it? nowadays it's a unit file (basically just an ini file) away with relatively straightforward API. and you can actually declare startup dependencies and other useful relationships past just "prepend a number signifying when it should run globally to the front of the filename". it's provided an extensible platform with which higher level orchestration frameworks like ansible / ignition can easily templatize services or other system configuration.

since the beginning of systemd people have moaned about how complex it is and how we're reinventing the wheel. yet time and time again the people actually working on the project show that the solution they've come up with is the result of the problem they're facing on a daily basis. it's quite annoying that the armchair linux experts complain about how "lol systemd is so stupid for reinventing the wheel, give me my shell scripts back", maybe think about whether or not you have a legitimate issue not being addressed by the solution proposed or if you are just getting rage baited by a headline.

replies(17): >>40208249 #>>40208286 #>>40208374 #>>40208481 #>>40209110 #>>40209185 #>>40212620 #>>40212965 #>>40214704 #>>40214800 #>>40214923 #>>40215163 #>>40215552 #>>40215793 #>>40216445 #>>40217144 #>>40217617 #
agilob ◴[] No.40214923[source]
> remember when you had to write bash scripts to start, stop, restart services

This was a really big pain, yes, but I also remember how I could `tail -f *.logs`. I remember how I didn't need to remember about `--no-pager` and `--follow`. I knew where the files were, what they were called. I remember how I didn't have to google how to find logs between 10 days ago and 4 days ago, because the logs would be in a .tar created by logrotate with a date in the filename.

The init system was probably peak of systemd, after that they started reinveting things in a more complicated way. Do we really need journald, systemd-boot, machinectl, systemd-networkd, sd-bus, systemd-resolved, systemd-nspawn? Do people actually use it all? Are there any metrics to show how many systems have it installed and in use?

replies(8): >>40215028 #>>40215089 #>>40215154 #>>40215742 #>>40216065 #>>40216893 #>>40217407 #>>40218927 #
lolinder ◴[] No.40215154[source]
> I could `tail -f *.logs`. I remember how I didn't need to remember about `--no-pager` and `--follow`.

journalctl supports -f, which by your own account you were already using for tail, so I'm not clear what's worse there.

> I remember how I didn't have to google how to find logs between 10 days ago and 4 days ago, because the logs would be in a .tar created by logrotate with a date in the filename.

My memory of this time was that every single application had its own unique method of handling logs and its own unique location for storing them. So sure, once you found the logs you didn't have to Google how to find the relevant dates if the application is using logrotate as you describe, but finding the logs in the first place was always a challenge. Systemd is nice in that it provides a single place where all logs go and a single interface for navigating them.

replies(7): >>40215510 #>>40215749 #>>40216628 #>>40216689 #>>40216818 #>>40218944 #>>40225179 #
1. citrin_ru ◴[] No.40216818[source]
'journalctl -u service -f' takes many seconds to start showing logs (even with 4GB journal size limit which not that much). 'tail -f /var/log/service' works without a noticeable delay (be it 1kb or 100Gb log file). For me it's a huge regression.
replies(1): >>40216992 #
2. rezonant ◴[] No.40216992[source]
While I'm very pro journalctl, this is very true. They should put some work into the initial read performance on big journals.