Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Systemd by Example (2021)

seb.jambor.dev

Post reply on HN
Print view View original

71–80 of 115 posts

Re: Systemd by Example (2021)

#71

Post by lloeki »

pnutjam wrote: post #53
lloeki wrote: 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

> a lot of old school "cron" users who don't touch the better "anacron" processes

You're touching on something subtle where, like markdown, all cron look the same until they differ.

Re: Systemd by Example (2021)

#72

Post by Karellen »

js2 wrote: post #59
Karellen wrote: post #44

Earlier quoted context omitted.

As well as the already-mentioned `n * * * *` solution, there's also dropping a symlink in /etc/cron.hourly to the program to run. Or a 2-line shell script if you need to add command-line params. (The other line is the shebang.)

The cron.hourly directory is a non-standard Linux concept provided by run-parts. The FreeBSD equivalent is periodic, but that's really for system tasks and doesn't have anything more granular than daily.

Yeah, but the comparison was specifically comparing to systemd timers, so I'm pretty sure the GP wasn't considering non-Linux compatibility anyway.

Re: Systemd by Example (2021)

#73

Post by fsflover »

op00to wrote: post #51
zb10948 wrote: post #35

Earlier quoted context omitted.

That's serveral conjectures on your part. Give me metrics about the minority and then back up the fact that most of those people never wrote a sysinit or rc script by hand. Like it or not Systemd breaks the Unix way and for a certain amount of people (I am not pretending to have a measuring stick) the dogma and philosophy are much more important than perceived ease of use or features.

Why would I care about "breaking the Unix way"?

It's outlined here: https://en.wikipedia.org/wiki/Unix_philosophy

Re: Systemd by Example (2021)

#74

Post by bheadmaster »

yau8edq12i wrote: post #69
bheadmaster wrote: post #47

Earlier quoted context omitted.

Portable has a well-defined meaning. You can argue that no other system matters (which I strongly disagree with for reasons I don't want to get into right now), but that doesn't make systemd timers any more portable.

Okay, can you define precisely what portable means?

Portable means easy to make it work while changing the underlying system or its implementation details - where the underlying system refers to architecture, OS, API or any other dependencies needed to run the program.

In context of systemd, systemd isn't portable because it highly depends on Linux API and thus cannot be ported on any other UNIX-like (or unlike) OS.

In context of systemd timers, systemd timers aren't portable because there isn't as single alternative implementation that can interpret systemd timer unit files.

Re: Systemd by Example (2021)

#75

Post by bheadmaster »

cjaybo wrote: post #67
bheadmaster wrote: post #47

Earlier quoted context omitted.

Portable has a well-defined meaning. You can argue that no other system matters (which I strongly disagree with for reasons I don't want to get into right now), but that doesn't make systemd timers any more portable.

I’d argue that the degree of portability implied by the term is very much context dependent. “Portable between Linux systems” is a perfectly valid use of the term, imo. Do you take portable to mean a program that can run on every processor arch and OS available?

> Do you take portable to mean a program that can run on every processor arch and OS available?

The definition of the word "portable" is not the point of this comment thread (although if you want to hear my definition, see the reply to a sibling comment).

Let's take the context into account:

    > hashworks:
    While I support systemd timers over cron, AFAIK cron has stuff like @hourly.

    > caiusdurling:
    Some cron implementations do, it's not portable.

    > bheadmaster:
    Neither are systemd timers. I don't think there's a single system out there implementing the systemd timer interface.
User caiusdurling said @hourly is not portable between cron implementations as a way to discredit hashworks' argument about cron having @hourly.

However, that's a disingenious argument, because systemd timers aren't any more portable than cron implementations that use @hourly - in fact, there isn't a single system out there implementing the systemd timer interface except systemd.

Re: Systemd by Example (2021)

#76

Post by js2 »

yau8edq12i wrote: post #68
js2 wrote: post #49

Earlier quoted context omitted.

systemd is is many things, but obvious and accessible is not one of them. It has a lot of power and flexibility, but the trade off is a lot of complexity. Just look at the unit configuration file: https://www.freedesktop.org/software/systemd/man/latest/syst... I've never heard of a systemd timer before, but I guessed it was a type of unit file, so I just read the documentation: https://www.freedesktop.org/software/sy…

I'm not quite sure why you felt pressed to write this long-winded response to something I didn't write. I never said that systemd is easy. I said that if someone is running *BSD, today, in 2024, they'll cope with cron's syntax. I'll still reply to one part: > Oh, I see I can use "hourly" but it turns out that's syntactic sugar for: > *-*-* *:00:00 >Is that really any easier than the cron equivalent? > 0 * * * * ...Ye…

Hah, that's fair. I inferred from your comment the corollary that systemd is not arcane, and thought "oh, it's just arcane differently," hence my long-winded reply.

Re: Systemd by Example (2021)

#77

Post by marcosdumay »

doix wrote: 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 wanted. So it's showing no errors with this service... does that mean the service has no errors?

Re: Systemd by Example (2021)

#78

Post by enriquto »

dingnuts wrote: post #70
michaelcampbell wrote: post #63

Earlier quoted context omitted.

> I'm always surprised by how many developers don't grok despite understanding significantly more complex things. You used git as a (counter?) example, but for me systemd has this issue because it's because I touch it so infrequently that whatever I learned about it has aged out of mental cache. I have the same issue with `jq`, GNU `parallel`, and `ffmpeg` (which I'll grant even if I used it daily I probably wouldn't…

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 ? or journalctl -u unitfilename -f to follow the logs -- the very same flag tail uses? after a decade of systemd usage I've never once had to actually think about the format the logs are stored in, or where they're st…

> 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 is independent of the program that produces it. Why implement the -f option on other programs when it is already implemented in tail?

Re: Systemd by Example (2021)

#79

Post by mksybr »

klysm wrote: post #48
bmicraft wrote: post #37

Earlier quoted context omitted.

Naively, I'd expect `ExecStop=` to just work™. Is this not the case?

The issue would be blocking the network coming down.

I think something like:

  Wants=network-online.target
  After=network-online.target
  Before=shutdown.target
  DefaultDependencies=no

Re: Systemd by Example (2021)

#80

Post by dingnuts »

enriquto wrote: post #78
dingnuts wrote: post #70

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 ? or journalctl -u unitfilename -f to follow the logs -- the very same flag tail uses? after a decade of systemd usage I've never once had to actually think about the format the logs are stored in, or where they're st…

> 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 discover the service name by calling systemctl status, or I can just call journalctl with no arguments and pass directly to grep to find what I need, in whatever unit it's in.

Try that when you have log files scattered all around your filesystem.

Post reply on HN