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

61–70 of 155 posts

Re: Systemd.timer, an Alternative to Cron

#61

Post by [deleted] »

rektide wrote: post #33
traverseda wrote: post #25

Earlier quoted context omitted.

>And what if you want multiple timers, with different configurations between them (maybe one long running one with WakeSystem= and a shorter one without?). Well, that's where you can write a regular timer or just add a dependency to your timer-service. But also you're sort of getting to the territory of inventing your own scripting language on top of systemd at that point, if your needs are that complex just write a…

This feels quite dismissive to me. I dont see the appeal of any of these three options, given how well systemd.timers solve all of this today & how nicely they compose. The whole point is to not need to keep running into a bunch of artisinal handcrafted did-it-myself shell scripts every time come to a system. Being able to compose timers that trigger units enables this nicely with a lot of flexibility. Managing them…

[deleted]

Re: Systemd.timer, an Alternative to Cron

#62

Post by traverseda »

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…

>We also cant just disable a timer temporarily

Sure you can, comment that line out of the service file. It is ultimately just a text file that you can edit.

Re: Systemd.timer, an Alternative to Cron

#63

Post by mongol »

whateveracct wrote: post #2

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

Systemd and NixOS feels like a great fit. It is easier to configure than the real thing and also short scripts are easier to tie together with services and timers. All in one file instead of 2 or 3.

Re: Systemd.timer, an Alternative to Cron

#64

Post by [deleted] »

gnaritas99 wrote: post #51
pikrzyszto wrote: post #15

Earlier quoted context omitted.

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

No, having a special way to tail your special log file isn't a feature, tail is a general utility used system wide for this for decades; breaking this is idiotic no matter what you grew up with.

[deleted]

Re: Systemd.timer, an Alternative to Cron

#65

Post by klodolph »

jamespwilliams wrote: post #54
luckycharms810 wrote: post #37

While I agree Systemd timers aren't as ergonomic to set up - there are some benefits that I would basically never give up at this point. * Running the service on command ( this is the best way to troubleshoot issues with your slightly different environments / cron's version of shell. I've spent many minutes over my career - setting the crontab one minute and the future and waiting for it to run / fail ) * Easily insp…

* Built in locking (so you don't need to worry about two instances of your cron running at the same time) * Built in functionality for telling when the cron last ran, and whether it was successful or not (so you can do alerting) * Ability to specify human-readable schedules * Built-in feature for randomising cron start time to avoid stampeding

The built-in locking is IMO a big deal.

If you have a script that you run every 24 hours, what happens when it takes 25 hours to complete?

(My experience is that this happens only years later, and the people who wrote the cronjob are gone.)

Re: Systemd.timer, an Alternative to Cron

#66

Post by ciupicri »

lazide wrote: post #19
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…

Well, except for /etc/crontab, /etc/corn.daily|weekly|whatever, /var/spool/crontabs, etc.

/etc/cron.{hourly,daily,weekly,monthly} are just some convenience shortcuts. No one is forcing you to use them.

Re: Systemd.timer, an Alternative to Cron

#67

Post by dale_glass »

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 do when testing it!

With cron this is troublesome, because cron uses an environment different from what you get from the commandline. So things can work from the shell and not from cron.

So to really check that cron works you have to add a line to be called in 5 minutes, then check your mail to see what happened.

With systemd though, you can launch the service at any time and see what it does without all that fiddling.

Re: Systemd.timer, an Alternative to Cron

#68

Post by dralley »

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 will run next, and how much time is left until that happens.

Re: Systemd.timer, an Alternative to Cron

#69

Post by dale_glass »

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.

Then it'd be annoying if you have to stop a timer temporarily

Re: Systemd.timer, an Alternative to Cron

#70

Post by dale_glass »

sparker72678 wrote: post #7

You can pry my crontab out of my cold, dead hands. Seriously, though, cron has been so utterly reliable for me for so many decades now, it will be really hard for me to ever give it up.

What's reliable about it?

Cron requires manual locking, which results in an old service sometimes aborting without cleaning that up, and then refusing to start ever since.

I'm precisely in the middle of an update that's going to throw that out, and just change to a systemd service/timer. Then that problem will go away for good.

Post reply on HN