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

71–80 of 155 posts

Re: Systemd.timer, an Alternative to Cron

#71

Post by alyandon »

dralley wrote: post #68
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…

> Don't glance at a crontab to see when things will next execute, run some other tool that will inspect everything for you. Make things more complex and difficult to read, and then write tools to make it easier to read again. systemctl list-timers is vastly more informative in a practical sense than just looking at the crontab. It just straight up tells you exactly when it ran last, how long ago that was, when it wil…

More importantly, you don't have to worry about fat-fingering an entry in your crontab and having everything from that point onward silently fail.

Re: Systemd.timer, an Alternative to Cron

#72

Post by rfmoz »

ilyt wrote: post #50
rektide wrote: post #22

Earlier quoted context omitted.

'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.

It’s odd, but actually you can not restart an active unit with a timer

Re: Systemd.timer, an Alternative to Cron

#74

Post by jeroenhd »

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 can't count the times I've had to debug cron scripts by copying the cron command line and running it through sudo because the script ran into an edge case, only to find out I didn't have the exact cron environment so manual runs didn't trigger the bug.

I much prefer the systemd solution. As an added bonus, systemd services allow for easy configuration of things like sandboxes and resource limits that would need to be hacked into a giant concatenated command line in cron, presumably without comments even.

Re: Systemd.timer, an Alternative to Cron

#75

Post by kzrdude »

phpisthebest wrote: post #11
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…

>>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…

Why isn't the timer stuff just an optional [Timer] in a unit file? Then it would be separate (separate section), even if it's in the same file.

Re: Systemd.timer, an Alternative to Cron

#76

Post by dale_glass »

smm11 wrote: post #44

Quoted post unavailable.

I never quite understood that criticism, since systemd is extremely unapologetically Linux centric.

It uses all the cool features of the kernel. It's configured with text files, and has an override system that works great with the Linux filesystem layout and package manager -- much better than SysV init, by the way. And it handles a lot of little annoyances that have long been a thorn in an admin's/user's side on Linux.

Re: Systemd.timer, an Alternative to Cron

#77

Post by Arnavion »

ravi-delia wrote: post #56
superkuh wrote: post #46

Earlier quoted context omitted.

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.

This would be needlessly insulting if it were posted as a top level comment, but as a direct reply to a Nix user it is impossible to read as anything other than the worst of condescension. Can you really say this is a net improvement to the tone of the conversation in this thread?

Wouldn't be a systemd thread without shitposting in every other comment. Just flag and move on.

Re: Systemd.timer, an Alternative to Cron

#78

Post by jeroenhd »

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

Maybe nginx logs at usable, but my experience with reading logs in the old way was often "grep servicename syslog" and prayer that the tool didn't have its own magical log file somewhere else.

The backing store may be controversial, but the journalctl command line is much more pleasant. "I want to see log messages from the end of the last boot when the system crashed" is no longer a Rube Goldberg command line involving less/sed/grep/cut/awk and manual scrolling, it's supported out of the box with no configuration necessary.

Re: Systemd.timer, an Alternative to Cron

#79

Post by ThatGeoGuy »

dale_glass wrote: post #76
smm11 wrote: post #44

Quoted post unavailable.

I never quite understood that criticism, since systemd is extremely unapologetically Linux centric. It uses all the cool features of the kernel. It's configured with text files, and has an override system that works great with the Linux filesystem layout and package manager -- much better than SysV init, by the way. And it handles a lot of little annoyances that have long been a thorn in an admin's/user's side on Lin…

Some parts are extremely Linux-centric.

I'd argue the better parts of systemd (it's not all bad but there's a lot of low-hanging fruit for all of us to gripe and bicker about) are the imaginings that came from launchd. That for sure was more UNIX centric than "linux" in particular.

You're right that the criticism "just become windows" seems weird - if anything else one should just say "get a mac" since that's where a lot of the launchd ideas originated.

Re: Systemd.timer, an Alternative to Cron

#80

Post by cookiengineer »

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…

Counter argument: Try implementing support for Alpine, Debian and other distros whilst using a cronjob.

It's impossible. All that opinionated /etc/crontab and /etc/cron.daily shit can go to hell for all I care. Every opinionated distro uses whatever kind of file format that the next best sh guru came up with, which id also prone for exploitation btw.

With systemd there's a failsafe way for maintainers to offer a cross-distro way to integrate their software.

And that's what systemd is about: automation of integration through convention.

Post reply on HN