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

Love systemd timers

blog.tjll.net

Post reply on HN
Print view View original

91–100 of 309 posts

Re: Love systemd timers

#91

Post by ssl-3 »

Blackthorn wrote: post #59
tobyhinloopen wrote: post #54

Earlier quoted context omitted.

Epson Ecotank. I’ve been using mine for years and I only had to buy new ink once. And I printed a lot of photos, notes, documents, etc

Those will still get their nozzles clogged if you don't run them.

This is the part where I get to point out that Brother inkjets do a little dance ~every day that keeps the heads fresh. They do this on their own as for long as they're powered up.

This allows them to work well even if years go by between prints. It's a very thoughtful design element.

(They don't survive sitting for months and months unpowered on a shelf very well, but... you'll have that.)

Re: Love systemd timers

#92

Post by eqvinox »

jerf wrote: post #79
thomashabets2 wrote: post #57

I haven't used systemd timers enough to disagree, but > Ambiguous $PATH settings make cron script execution difficult to predict. What makes you say that? You can set the PATH right in the crontab. Is that harder to "predict" than it being set in /etc/bashrc, ~/.bashrc, ~/.profile, ~/.bash_profile, /etc/systemd/…, or wherever else? > You might feel cool knowing the scheduling grammar by heart I've used Linux since 19…

"You just put numbers aligned with the titles." That is not a fair summarization of their point because that is not the grammar. There's commas, slashes, asterisks, combinations, and then if you want randomization you need to put it in the command itself because cron can't do it. (Some crons can, but it's not a general capability of cron.) Writing a non-trivial cron spec is not easy.

How do you express those things in a systemd timer? E.g. run something 4x per day, */6 in cron.

Re: Love systemd timers

#93

Post by gchamonlive »

happysadpanda2 wrote: post #87
gchamonlive wrote: post #77

Earlier quoted context omitted.

> That isn't something I'd want to happen, it sounds like it creates a potential queue of scripts that will flood the system on start, if it works the way you described. This isn't what happens. If you leave it offline for days it'll only trigger the service only a single time.

I interpreted it more like "I have these 500 different cronjobs all spread out across $unit_of_time. If the system is down for longer than $unit_of_time and then comes back, does all 500 jobs start running instantly (since they missed their previous deadline)?"

Just to be clear, this isn't default systemd timer behaviour, you need to opt in by setting Persistent=true. If you have hundreds of jobs like this you need a proper queue and neither cronie nor systemd is the right tool because at that scale you'd surely need better observability

Re: Love systemd timers

#94

Post by gchamonlive »

bisby wrote: post #90
gchamonlive wrote: post #77

Earlier quoted context omitted.

> That isn't something I'd want to happen, it sounds like it creates a potential queue of scripts that will flood the system on start, if it works the way you described. This isn't what happens. If you leave it offline for days it'll only trigger the service only a single time.

If you have 100 different jobs that were supposed to run over the past week, but didn't because offline, when you restart, they they all flood the system on start. 100 jobs all running at different times throughout the week is a very different load than them all falling back and running at the same time on system boot.

I don't, it's a single backup service.

Re: Love systemd timers

#95

Post by networked »

jeroenhd wrote: post #84
thomashabets2 wrote: post #57

I haven't used systemd timers enough to disagree, but > Ambiguous $PATH settings make cron script execution difficult to predict. What makes you say that? You can set the PATH right in the crontab. Is that harder to "predict" than it being set in /etc/bashrc, ~/.bashrc, ~/.profile, ~/.bash_profile, /etc/systemd/…, or wherever else? > You might feel cool knowing the scheduling grammar by heart I've used Linux since 19…

Having had to work on an application supposedly supporting cron expressions: the numbers are just the basic parts of the language. When someone inputs something ridiculous like "5,3/4 4-8,11 1 4,5,6,9-11 */2" you get to enjoy the fun of reverse engineering what they meant (it's never what they actually wrote). And that's before you get to all the extensions supported in some cron environments (but not all). I find sy…

Complex expressions are one of the things I don't like in cron. On Debian/Ubuntu servers, I just bite the bullet with systemd timers. On my workstation, I have a personal job scheduler that feels easier and more fun to tinker with. The scheduler uses Starlark functions instead. For example:

  # Run if at least a day has passed since the last run
  # and it isn't the weekend.
  def should_run(finished, timestamp, dow, **_):
      return dow not in [0, 6] and timestamp - finished >= one_day
This was inspired by GNU mcron. In mcron, jobs can calculate the next time they should run using Guile (https://www.gnu.org/software/mcron/manual/mcron.html#Guile-S...):

  (job
     '(next-minute-from
        (next-hour (range 0 24 2))
        '(15))
     "my-program")
I found mcron's scheduling counterintuitive and decided I wanted a function that returned a boolean. I can tentatively recommend it.

Re: Love systemd timers

#96

Post by tekno45 »

sunrunner wrote: post #49
tdeck wrote: post #42

Earlier quoted context omitted.

I wish printers could have a mode like this to print random images from an album, or a calendar, rather than wastefully draining ink into a sponge every few days. If nothing else, maybe it could be some kid's high school science fair project idea.

How about printing a QR code for a randomly generated private key for Satoshi Nakamoto's Bitcoin wallet, then every few days you get a tiny moment of excitement, hope, and then disappointment. It's still wasteful, but it could pay off big time?

this is an amazing youtube video idea if you could get a type writer to do it.

Re: Love systemd timers

#97

Post by MathMonkeyMan »

chuckadams wrote: post #81

I believe one of the major distro lines (redhat or debian, I forget which) uses systemd-cron, where cron is just a thin wrapper around systemd. You get more power from writing the unit files directly, but if all you ever need is a simple cron job, you have the old interface still available.

Yep, I use this for a @reboot job and a few regular jobs on my home server. I use user crontabs, so I can get around the "unknown shell/path/etc." by prefixing every job with

    /some/shell -l myjob.sh
or sometimes

    . ~/.profile && cd /some/where && ./job >>cron.log 2>&1

Re: Love systemd timers

#98

Post by dmuth »

> stdout and stderr output often ends up in a black hole

Ain't that the truth. Literally every crontab I've written for the last 10 years has had this in it:

2>&1 | logger -t cron-WHATEVER

...and that does a pretty good job of capturing anything that the script emits and making it easy to grep for in syslog the following morning.

But I'm still amazed at how many crontabs I run across that don't capture any output at all.

Re: Love systemd timers

#99

Post by egorfine »

thomashabets2 wrote: post #57

I haven't used systemd timers enough to disagree, but > Ambiguous $PATH settings make cron script execution difficult to predict. What makes you say that? You can set the PATH right in the crontab. Is that harder to "predict" than it being set in /etc/bashrc, ~/.bashrc, ~/.profile, ~/.bash_profile, /etc/systemd/…, or wherever else? > You might feel cool knowing the scheduling grammar by heart I've used Linux since 19…

> I've used Linux since 1994

Same here.

We are now considered old and therefore irrelevant. The new generation uses timers and couldn't care less about cron that has served us just fine for decades.

I use cron and my general attitude towards LP and systemd is very similar to the attitude of LP and systemd to us.

Re: Love systemd timers

#100

Post by egorfine »

kayson wrote: post #65

I love systemd timers! I've slowly moved all of my ansible-deployed cron jobs to timers (now just an ansible copy!). The integration with journalctl, especially in a newer OS like Debian 13 where syslog is gone, is really nice. It's also really nice to be able to start the service manually for debug. Having a cron job that didn't work was an annoying exercise in copy/pasting or writing an extra shell script. Don't ev…

> more and more open source projects recommending timers

I am perfectly happy with projects recommending timers as long as I can ignore them and use cron.

Post reply on HN