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

141–150 of 309 posts

Re: Love systemd timers

#141

Post by bakugo »

egorfine wrote: post #125
bakugo wrote: post #122

Earlier quoted context omitted.

Has it actually served you well? Because it hasn't served me well at all. I am not the biggest fan of systemd, but today I will always reach for a systemd timer over cron simply due to the sheer amount of bad experiences I've had with cron. Hours upon hours wasted trying to troubleshoot crons that weren't working due to some stupid obscure issue, having to use dirty hacks to monitor for success or retry failed jobs.…

Let me state once again: "within its very clear limitations". Once you learn that env in cron is not same as in your shell and once you learn to redirect output to loggers - it works just fine. It would be a lie to say that I never debugged cron and sure it's annoying. > and the script just died halfway through for no reason Unrelated to cron. Bad script.

I don't agree that these are just limitations. The fundamental problem cron tries to solve is very simple: I want to run a program automatically at specific times. There are probably many features of systemd timers that can be considered niche or extraneous in solving this problem, but the ability to easily know when the program last ran and what its exit code and stderr output were is not one of them. I believe that if an alleged solution to this problem doesn't provide at least this, it's not really solving the problem.

> Unrelated to cron. Bad script

Again, worked fine when run manually, worked fine in a systemd timer. Pretty sure I still have it running today and it continues to work fine without ever failing.

Re: Love systemd timers

#142

Post by arter45 »

louiskottmann wrote: post #139

And you immediately lose the ability to do `crontab -l` on any server to know its scheduled tasks. Now you get to look around the myriad of places where you can put systemd files, and figure out which ones are base services and which ones are custom, with no general convention to go about it. Nope.

systemd list-timers

With —-all

Re: Love systemd timers

#143

Post by dijit »

the_real_cher wrote: post #58
pwdisswordfishq wrote: post #31

Earlier quoted context omitted.

That the same cannot be said of its maintainer is another matter.

The main person in charge of Linux itself isn't considered the most humble but they make amazing products.

Linus is pretty humble tbh, he just expects that people don't throw shit over the fence.

Re: Love systemd timers

#144

Post by TazeTSchnitzel »

louiskottmann wrote: post #139

And you immediately lose the ability to do `crontab -l` on any server to know its scheduled tasks. Now you get to look around the myriad of places where you can put systemd files, and figure out which ones are base services and which ones are custom, with no general convention to go about it. Nope.

If you had read the article, you would have seen its answer to this.

Re: Love systemd timers

#145

Post by simoncion »

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…

> 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

Nope. From crontab(5)

  The  RANDOM_DELAY variable allows delaying job startups by random amount
  of minutes with upper limit specified by the variable. The random  scal‐
  ing  factor  is  determined during the cron daemon startup so it remains
  constant for the whole run time of the daemon.
That's from my cronie install, but it looks like this has been a feature of some crons for at least a decade. (Notice that the post date of [0] is in 2016.) Given that cronie is based on vixie-cron, and I think I was was using vixie-cron in 2002, I bet it's been a thing for at least twenty years.

[0] https://stackoverflow.com/a/34815984>

Re: Love systemd timers

#146

Post by sunrunner »

tekno45 wrote: post #96
sunrunner wrote: post #49

Earlier quoted context omitted.

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.

Maybe I'm misremembering, but I'm sure there was something on HN a few weeks ago about an electric typewriter that someone had connected to (I'm guessing) a Raspberry Pi? My search-fu is currently failing to find anything particularly recently, at the moment.

Re: Love systemd timers

#148

Post by dogleash »

erxam wrote: post #138
egorfine wrote: post #125

Earlier quoted context omitted.

Let me state once again: "within its very clear limitations". Once you learn that env in cron is not same as in your shell and once you learn to redirect output to loggers - it works just fine. It would be a lie to say that I never debugged cron and sure it's annoying. > and the script just died halfway through for no reason Unrelated to cron. Bad script.

Systemd will reign supreme for a millennium if the answer to every question or complaint about non-systemd tools is "you're holding it wrong".

As a user I'm kinda whatever about the tools because the answer to my complaints about systemd is also "you're holding it wrong."

Re: Love systemd timers

#150

Post by simoncion »

mkesper wrote: post #89
6031769 wrote: post #86

Earlier quoted context omitted.

Of course you can do this trivially in cron as well. It is what the CRON_TZ variable is for.

This is a GNU extension so not portable.

> This is a GNU extension so not portable.

1) It's supported by cronie. I bet it's supported by many other crons.

2) "Great" news! The software in the Systemd Project only officially runs on Linux, so "it's not portable" is a really bad counterargument when "alternatives to some Systemd Project feature" is the discussion topic.

Post reply on HN