Live data from Hacker News

Systemd by Example (2021)

seb.jambor.dev

81–90 of 115 posts

Re: Systemd by Example (2021)

#81
post #53
post #29

Earlier quoted context omitted.

Debugging and tracability is just nuts too. With a timer and a run-once service it's easy to see what happens, happened, and will happen: systemctl status foo.timer tells you when it has last triggered and when it will triggered next, if it is still enabled. systemctl status foo.service tells you if it has been triggered from the timer and when, or ran manually with start I get the conceptual utter simplicity of cron…

Exactly, and there are still alot of old school "cron" users who don't touch the better "anacron" processes. I hate managing that stuff. Systemd > Anacron > Cron

Even worse, when I was finding "crons" run from Java apps with cron4j. I hated on SystemD a lot in the early days, and there are still many legit criticisms that don't have good answers, but I have come to appreciate it's power and usefulness very much. Writing your own units seems so much cleaner than the old way, and I say that as a everyday bash script writer/user. (example, systemd-nspawn for containerization)

PS: mcron is what I have been tinkering with and think will probably replace my systemd timers for most purposes.

https://www.gnu.org/software/mcron/manual/mcron.html#Introdu...

Re: Systemd by Example (2021)

#82
I haven’t been in the weeds with systemd for a while, but this post was very helpful in understanding how systemd actually works, which didn’t match my (or, I would think, nearly anyone’s) intuition as a user of it. I don’t know if there’s any other full technical explanation of how units, jobs, transactions, etc. are actually handled.

https://blog.darknedgy.net/technology/2020/05/02/0/index.htm...

>systemd’s developers and almost all public documentation revolve around a “unit-centric” definition of systemd (except when discussing bugs), but my position is that for systemd-the-service-manager the most important construct is not the unit but the job, and hence one ought to understand systemd in a “job-centric” way.

Re: Systemd by Example (2021)

#83
post #60
post #45

Earlier quoted context omitted.

All the major distros, especially server distros, run systemd. That is proof enough that NOT running systemd is a niche and unsupported configuration in any half-serious setup. A conjecture is not automatically wrong. The point of a conjecture is to challenge someone else to prove it wrong. You'd have a hard time showing proof that systemd is niche. And honestly, it does not break UNIX , let's be serious now. A hapha…

> I am an engineer with software to run and deadlines to meet. Sure, but UNIX, with its minimalist philosophy, was - luckily for us! - not created under that slogan. With respect to quality, this slogan has always been the one driving its decrease that we see all around us today.

UNIX was created by engineers to run software, not as a philosophical device.

Sorry to say, yours is a terrible excuse. I respect that you might not like systemd, no software is perfect and systemd has many flaws, but the "think of the UNIX philosophy" is righteous nonsense that I cannot take seriously.

The real world is not black-and-white, with or against us. One of the most beloved UNIX tools, Emacs, is as far removed from the minimalist philosophy that some have decided to be UNIX's crowning achievement. It is not. Linux and UNIX have not won because we're all into minimalism, or dogmatic zealotry.

Re: Systemd by Example (2021)

#84
post #21

Earlier quoted context omitted.

Not a lot of people, a very loud minority. They can go use Void Linux or other niche distros which replace it with the monstrosity that were SysV init scripts. It's the type of people that never had to write one of those scripts by hand, and maybe support two or three different distros. The UX of systemd tools (systemctl, journalctl) is a bit crap, to be honest, but systemd does what it needs to do well and it is an…

> monstrosity that were SysV init scripts I'm really tired of people pretending that systemd is the only modern init system around. If you're going to compare it to the status quo, at least don't strawman it. If SysV init scripts are your comparison, it just sounds like you're regurgitating outdated talking points.

> systemd is the only modern init system around

I never said it was. I said it's the only relevant one. Upstart was half-decent, for example, but no one uses it any more. Yes, there are other modern init systems, none that are so brilliantly designed and perfect that are worth this kind of resistance. They're all crappy in their own way. So what if systemd has won.

I do not get why people want to die on this inconsequential hill.

> regurgitating outdated talking points

No, I'm not being paid by Poettering. I've been running Linux systems and software for 25 years, and I have formed my opinion on the matter, thank you very much.

Re: Systemd by Example (2021)

#85
post #28
post #21

Earlier quoted context omitted.

Not a lot of people, a very loud minority. They can go use Void Linux or other niche distros which replace it with the monstrosity that were SysV init scripts. It's the type of people that never had to write one of those scripts by hand, and maybe support two or three different distros. The UX of systemd tools (systemctl, journalctl) is a bit crap, to be honest, but systemd does what it needs to do well and it is an…

> The UX of systemd tools (systemctl, journalctl) is a bit crap, to be honest Huh, what do you mean? I'm pretty happy with those.

I really dislike that systemctl subcommands do not respect the accepted standard of `command subcommand -h`. For example, try `git branch -h` or `systemctl start -h`. The latter won't give any useful information.

The man page does not help either. `man git branch` opens the manual of the `git-branch` binary, so only the relevant options are shown. `man systemctl start` will show the man of the entire systemctl command, which is a bit unwieldy.

`journalctl` is the same: it both does paging through the logs, but also manages rotating or vacuuming the logs. Why not have two commands?

Re: Systemd by Example (2021)

#86
post #43

Ha, systemd is basically my git. I'm always surprised by how many developers don't grok git despite understanding significantly more complex things. I keep thinking if they would just take a day or two, they would get it and then wouldn't complain about having to copy paste commands and "rm -rf && git clone" to fix their workspaces. And yet I do the _exact_ same thing with systemd. I don't get it, I don't like it, an…

It's hard to explain the problem with journalctl... it just always does something completely different from what I expect it to do. The option to fix it is always there, individualized by some rule that is completely different from what a command line interface tends to use, so it's mostly unrecognizable. It wouldn't really be that bad, except for the fact that it's very hard to be confident it's doing the job you wa…

This Digital Ocean guide [1] is my go-to explainer for journalctl. Digital Ocean has pretty good tutorials all round.

[1] https://www.digitalocean.com/community/tutorials/how-to-use-...

Re: Systemd by Example (2021)

#87

Earlier quoted context omitted.

> how on earth is remembering the location of some log file, buried in /var/log somewhere, hopefully, or maybe next to the application in /etc/ or /opt/, easier than remembering journalctl -u unitfilename ? This may seem obvious to you, but I for one find filenames much easier to remember. Of course the logs are inside /var/log (and not anywhere else). Moreover, with filenames, you can check your logs with a program…

That's the thing though, you have to remember filenames. I don't have to remember anything, just journalctl, because it can be run without any arguments and get logs for -everything that's running- including units I totally forgot about! More than once I've forgotten the name of some unit I wrote -- the same as I easily forget filenames for random services I've installed, and where I might have installed them. I can…

I concede it's as easy if you're just reading one log from one machine, but what if you're harvesting and/or merging multiple logs from multiple machines? It's much easier to do with simple unix tools and plaintext logs.

Re: Systemd by Example (2021)

#89
post #83
post #60

Earlier quoted context omitted.

> I am an engineer with software to run and deadlines to meet. Sure, but UNIX, with its minimalist philosophy, was - luckily for us! - not created under that slogan. With respect to quality, this slogan has always been the one driving its decrease that we see all around us today.

UNIX was created by engineers to run software, not as a philosophical device. Sorry to say, yours is a terrible excuse. I respect that you might not like systemd, no software is perfect and systemd has many flaws, but the "think of the UNIX philosophy" is righteous nonsense that I cannot take seriously. The real world is not black-and-white, with or against us. One of the most beloved UNIX tools, Emacs, is as far rem…

To be fair, "Unix philosophy" was originated by said engineers themselves.

https://en.wikipedia.org/wiki/Unix_philosophy

Speaking of emacs, it was created outside Unix, to be later reincarnated by Stallman as part of his "GNU's Not Unix" project.

Re: Systemd by Example (2021)

#90
post #13

A lot of people still probably hate on systemd, but it and journalctl are pretty nice to me.

I think it depends on what you get used to first. I only started using Linux back in 2016-17 (I'm 25), and for me systemd is just so insanely good compared to anything else I've tried. Maybe it's just because I never got used to what came before it or to current alternatives.

I also don't care that much about the "Unix philosophy" or whatever, so there's that.

Post reply on HN