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

161–170 of 309 posts

Re: Love systemd timers

#161

Post by PenguinCoder »

PunchyHamster wrote: post #129
eqvinox wrote: post #92

Earlier quoted context omitted.

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

That's simple but consider "run something 4x per day but randomize a delay by hour so all of the 200 servers doing that task won't run it all at once" In cron, you basically have to either use your configuration management to generate those times, or have a random delay script running before the command In systemd timers, it's just OnCalendar=0/6:00:00 RandomizedOffsetSec=60m and the offset generated will be stable f…

`* 1 * * * sleep $(( $(od -N1 -tuC -An /dev/urandom) \% 45 ))m ; `

Re: Love systemd timers

#162

Post by tim-projects »

egorfine wrote: post #111

We have used cron perfectly fine for decades and it served us well within its very clear limitations. But now obviously we were so blind and wrong all this time and the only true solution is of course systemd.

After reading this article I'm convinced that what we need is systemd timers fronted by a vibe coded crontab -e emulator.

Coz it's looks crazy complicated to set them up.

Re: Love systemd timers

#163

Post by helterskelter »

skydhash wrote: post #120
nailer wrote: post #117

Earlier quoted context omitted.

> But luckily it's pre-printed in the crontab as comments That's true, but most people don't know the numbered manual sections, so they get the docs for the cron table command not the cron table config file.

> That's true, but most people don't know the numbered manual sections, so they get the docs for the cron table command not the cron table config file. No `man man`? ;)

Man Man: the man with the strength of two men.

Re: Love systemd timers

#164

Post by tombert »

NikhilVerma wrote: post #39

I have a Canon printer, I actually can't trust that their print nozzle won't get jammed up after sitting idle for a while. So I had claude setup a systemd script to print a picture of my dog every week, I ensure it has enough CMYK spectrum to stress the printer. Its a nice surprise every monday as I sit on my desk to see a sudden picture pop up from the printer :)

I used to do something similar with an old Samsung ML-2010 back when I was in college the first time around.

I think it was software and not hardware, but for some reason when I had that printer hooked up to my computer and idle for more than a week, it would simply stop printing. I probably could have dug through logs and figured it out, but I instead set up a cron job to print a test page every Monday and Thursday. The test pages would just have something on the top that said something like LOL PRINTER WORKS.

This wasn't actually as wasteful as it sounds; I was taking a boatload of math courses and needed tons of scratch paper in order to do my problems. Since it was scratch paper and would eventually end up in the trash anyway, I would usually prioritize doing my problems on failed prints and/or test prints, and I would usually exhaust those and then use blank paper afterwards.

Re: Love systemd timers

#165

Post by max-privatevoid »

eqvinox wrote: post #92
jerf wrote: post #79

Earlier quoted context omitted.

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

It's a mystery to me why everyone tries to use OnCalendar here, when "n amount of times within a certain timeframe" can be done much more easily with OnActiveSec, in this case that'd be OnActiveSec=6h.

Re: Love systemd timers

#166

Post by thomashabets2 »

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…

Per other comments though, it looks like systemd's syntax when you want to specify something that's not just that one number is at least as complex.

Is your example (which I agree, looks cryptic) any less cryptic in systemd?

I asked jippity, and it said this:

    [Timer]
    OnCalendar=*-04,05,06,09,10,11-01 04..08,11:03/4,05:00
    OnCalendar=Sun,Tue,Thu,Sat *-04,05,06,09,10,11-* 04..08,11:03/4,05:00
To which I have to go: "what?"

> Things like having control over whether or not long-running jobs are allowed to overlap

With cron that's just prefixing the command with `flock -n `, but sure the "pick somewhere to put the lock" is probably better with systemd.

> Having to re-write commands and scripts because CRON had its own special PATH

Why? Wouldn't you just put that in the crontab? I don't even see this as different. It's in the cron config or the systemd timer config.

The other improvements you mentioned seem good.

Re: Love systemd timers

#167

Post by Fire-Dragon-DoL »

LaSombra wrote: post #159
pkal wrote: post #127

Earlier quoted context omitted.

I am familiar with the syntax, so I am biased ("*/3" and "12,14,20" makes sense if you are familiar with Unix tools), but it is still more intuitive to me than the systemd unit file syntax and usage. I know that I just have to edit /etc/cron or throw any executable file into /etc/cron.d/monthly and it will work on my system, but I cannot write a systemd timer file from scratch without looking it, and to do that I fir…

If you want to create a new systemd unit file you can run: $ sudo systemctl edit --force --full my-scheduled-work@.timer or $ systemctl edit --user --force --full my-scheduled-work@.timer

Why the @?

Re: Love systemd timers

#168

Post by capitainenemo »

gchamonlive wrote: post #73
newsoftheday wrote: post #71

Earlier quoted context omitted.

I'm sorry, I tried Googling the word "tolates" but I can't find any definition that makes sense? > runs the service as soons as the system is available. cron has the @reboot option which I use for a few scripts and works great.

Typo, I meant tolerates. Fixed it. Not an option either, because if I reboot two machines and the backup starts in both of them it'll cripple my NAS

How does systemd on the 2 machines avoid that? Are they communicating somehow?

Re: Love systemd timers

#169

Post by gchamonlive »

capitainenemo wrote: post #168
gchamonlive wrote: post #73

Earlier quoted context omitted.

Typo, I meant tolerates. Fixed it. Not an option either, because if I reboot two machines and the backup starts in both of them it'll cripple my NAS

How does systemd on the 2 machines avoid that? Are they communicating somehow?

No, just different cron schedules. If I just reboot a machine the job doesn't get triggered, only if I start a machine after the cron schedule should have been triggered. To be fair, if I start two machines in these conditions this will happen too, but such situation is much more manageable than rebooting too machines in a short period of time.

Re: Love systemd timers

#170

Post by capitainenemo »

stryan wrote: post #45
esperent wrote: post #34

Earlier quoted context omitted.

Why do you randomize your backup times?

Should have been more clear: I use RandomizedOffsetSec= to add a random offset to a set start time (usually 4am), to prevent overloading the backup server, not truly random start times.

As someone else noted, that's also a cron feature
Post reply on HN