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

Systemd.timer, an Alternative to Cron

andrewpillar.com

Post reply on HN
Print view View original

41–50 of 155 posts

Re: Systemd.timer, an Alternative to Cron

#41

Post by rlpb »

ghostpepper wrote: post #5
traverseda wrote: post #3

https://htmx.org/essays/locality-of-behaviour/ Locality of behavior is important. Note how this systemd-thingy is split into two separate files? It's like that a lot in systemd, whoever is doing the architecture doesn't seem to understand why locality of behavior would be desirable, instead taking the IDE approach of writing a bunch of tools to make managing the increased complexity more manageable. Don't glance at a…

Binary log files is another example of something that could have advantages in theory but never seems to work well in practice. What used to be "tail /var/log/nginx.log" is now man journalctl journalctl -u nginx journalctl | grep nginx go back to man page to look for more options to search etc

Your gripes all seem to boil down to your unfamiliarity, rather than anything specific that stands on its own as a problem. Unfamiliarity is understandable, but if that were enough to avoid progress, we wouldn't never have progress.

> ctrl+C because it's taking too long

Try --since=today. Then you end up in less, and that should be more familiar, including for search. This is then the equivalent of traditional daily rotating log files, with no other knowledge needed apart from --since and --unit (the latter is noted in "systemctl status" output as a reminder).

Then every further feature is an optional bonus.

Re: Systemd.timer, an Alternative to Cron

#42

Post by dinosaurdynasty »

throwaway894345 wrote: post #30
candiddevmike wrote: post #18

Earlier quoted context omitted.

I personally find journalctl -fu $service very cathartic, because I'm almost always typing this command when $service isn't working.

I really need to alias `journalctl -fu` to something because it's always so tedious to type all that out over and over when I'm trying to debug something. Also, is there any autocomplete for systemd unit names? Typing `journalctl -fu amazon-cloudwatch-agent` over and over and over is so much more tedious--ideally it would be something closer to `jctl amaz `.

There is autocompletion. It works by default on Pop OS and Debian. (You may need to install bash-completion and/or dbus if your install is very minimal.)

Re: Systemd.timer, an Alternative to Cron

#43

Post by vel0city »

ilyt wrote: post #34
phpisthebest wrote: post #11

Earlier quoted context omitted.

>>Locality of behavior is important. Even your own link talks about the Subjectivity of that opinion, and how LoB is often in conflict with DRY and SoC, both of which I support far more than LoB. In this context systemd favors Separation of Concerns, the the service is what is being run, and the timer is when is it being run... it is not that the devs do not "seem to understand why locality of behavior would be desir…

Right but you basically never run the service ran by timer manually, so on average it's just adding noise to equation. Having option for separate timer is all and well (after all you might want to use it to periodically start service, for example start some sync service after midnight) but for cron-like behaviour it should really have all in one option, perhaps by just adding [Timer] block in .service or vice versa

You might never run the service outside of a timer, but you may have multiple timers reference the same service.

Re: Systemd.timer, an Alternative to Cron

#45

Post by dinosaurdynasty »

ilyt wrote: post #34
phpisthebest wrote: post #11

Earlier quoted context omitted.

>>Locality of behavior is important. Even your own link talks about the Subjectivity of that opinion, and how LoB is often in conflict with DRY and SoC, both of which I support far more than LoB. In this context systemd favors Separation of Concerns, the the service is what is being run, and the timer is when is it being run... it is not that the devs do not "seem to understand why locality of behavior would be desir…

Right but you basically never run the service ran by timer manually, so on average it's just adding noise to equation. Having option for separate timer is all and well (after all you might want to use it to periodically start service, for example start some sync service after midnight) but for cron-like behaviour it should really have all in one option, perhaps by just adding [Timer] block in .service or vice versa

I'm constantly running the service ran by timer manually, mainly for debugging.

Re: Systemd.timer, an Alternative to Cron

#46

Post by superkuh »

whateveracct wrote: post #2

I quite like systemd timers with NixOS (configured in the Nix language). They've become a standard hammer for me.

Nix/Guix users would think that way. They've alrady given up on the concept of system libraries or a unified OS. systemd's writing of 2 config files per timer would be right at home for people that have to set up an entire OS environment every time they want to try to compile something somone else hasn't already written a nix script for.

Re: Systemd.timer, an Alternative to Cron

#47

Post by ilyt »

pikrzyszto wrote: post #15
ghostpepper wrote: post #5

Earlier quoted context omitted.

Binary log files is another example of something that could have advantages in theory but never seems to work well in practice. What used to be "tail /var/log/nginx.log" is now man journalctl journalctl -u nginx journalctl | grep nginx go back to man page to look for more options to search etc

"tail /var/log/nginx.log" is now "journalctl -fu nginx" or "jouranlctl -eu nginx". Not that much of a difference, it really depends what you grow up with. We could argue "tail" is ugly because you never know if it's "tail /var/log/nginx.log" or "tail /var/log/nginx/nginx.log". A nice feature is that journald gives you flags like "--boot" to see logs only emitted during a specific boot, or "--since '5m ago'" which is…

I'd recommend running strace on that journalctl command, you might be surprised what happens. It's even worse if you actually store journalctl logs on disk (most distros defer to storing it in ram). I have it set to store on disk and keep at most 1GB of logs

On my NAS

    # strace journalctl -u nginx 2>&1 |grep open |wc -l
    827
and curiously

    # strace journalctl -u baked-potato 2>&1 |grep open |wc -l
    827
(no i do not have baked-potato service on that machine)

It's DB implementation is utter garbage. It doesn't even organize files by time or really anything useful. If the binary database was a SQLite file with columns containing app name/log level/etc. it would actually be useful but current one is just shit.

Bonus round:

    #:/var/log/journal echo 3 >/proc/sys/vm/drop_caches
    #:/var/log/journal time journalctl -u nginx >/dev/null 2>&1

    real 0m3,232s
    user 0m0,036s
    sys 0m0,292s
    #:/var/log/journal echo 3 >/proc/sys/vm/drop_caches
    #:/var/log/journal time ag -R nginx . >/dev/null 2>&1

    real 0m2,531s
    user 0m0,004s
    sys 0m0,290s
slower than actually searching thru files directly...

Re: Systemd.timer, an Alternative to Cron

#48

Post by dinosaurdynasty »

pm90 wrote: post #13

I've had the opportunity to delve into systemd in a previous role. This sounds a bit weird, but its not easy to get started with, unless you're used to reading man pages. But once you're able to read man pages, all of systemd behavior is documented in the man pages. I do wish there were more human friendly docs though, especially for younger engineers used to better sorts of docs. Anyways, once you do get the hang of…

systemd has amazing documentation, you just have to read them...

Re: Systemd.timer, an Alternative to Cron

#49

Post by ilyt »

marbu wrote: post #9
traverseda wrote: post #3

https://htmx.org/essays/locality-of-behaviour/ Locality of behavior is important. Note how this systemd-thingy is split into two separate files? It's like that a lot in systemd, whoever is doing the architecture doesn't seem to understand why locality of behavior would be desirable, instead taking the IDE approach of writing a bunch of tools to make managing the increased complexity more manageable. Don't glance at a…

This split between service file (what is going to happen exactly) and a timer file (when it's going to happen) is ok for complex use cases, but it really feels a bit silly when a single cron line would do the trick instead.

there is cmdline shortcut for one-off ones at the very least

    systemd-run --user --unit=timer-name --on-active=60 /exec/path
will run it in 60 seconds

Re: Systemd.timer, an Alternative to Cron

#50

Post by ilyt »

rektide wrote: post #22
traverseda wrote: post #3

https://htmx.org/essays/locality-of-behaviour/ Locality of behavior is important. Note how this systemd-thingy is split into two separate files? It's like that a lot in systemd, whoever is doing the architecture doesn't seem to understand why locality of behavior would be desirable, instead taking the IDE approach of writing a bunch of tools to make managing the increased complexity more manageable. Don't glance at a…

'Make everything simple as it can be but no simpler'. To me your ask violates this. Timers augment the variety of existing service types, so your idea just doesnt work straight up, unless we severely limit the flexibility of what timers can be via the 'periodic' type. Or we make 'periodic-oneshot' 'periodic-serice' et cetera, which feels absurd. Perhaps we could leave Service= alone & just shoehorn each systemd.timer…

> And what if you want multiple timers, with different configurations between them (maybe one long running one with WakeSystem= and a shorter one without?). We eliniate a lot of creative ability by glomming stuff together.

It's not either-or situation.

The .service could just have [Timer] block

Then you could just put all in one file, or still have option of putting timer somewhere else.

Post reply on HN