systemd is great all around. Don’t listen to the boomers complaining about it because their cheese was loved.
(typo, i think). cheese was moved?
Love systemd timers
131–140 of 309 posts
Re: Love systemd timers
#132Earlier 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'm sympathetic, but "bad script" is an awful assertion.
We are all guilty of making bad scripts, bash is a disgusting degenerate language (and I love it). The way we learn to write good scripts is by writing bad scripts in enough amounts to get bitten by all the warts.
One thing I really love about cron, is that if you set up mail on the server (which: you should btw), then cron actually sends emails if it sees anything in stdout and stderr.
I am a dyed in the wool systemd non-believer, but I really do like the timers.
Re: Love systemd timers
#133> Prime Time for a Timer Primer
It's pronounced, "primmer."
Re: Love systemd timers
#134Earlier 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.
So basically it took you decades to learn all the bugs, UX issues and problematic quirks and now you're complaning someone built something better? :)
Re: Love systemd timers
#135Earlier quoted context omitted.
EDITED This isn't the same as with systemd timer because timer lets you specify when you want to run your service exactly and will fallback to running when the system comes online. With @hourly I lose this control and multiple machines could potentially trigger backups at the same time, hogging the physical hard drives and the network.
> fallback to running when the system comes online. 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. I prefer the deterministic behavior of cron, the script will run when it is specified to run, as you said earlier, as long as the system is running; and as I stated in a separate comment, it will run…
> 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.
There are two options to fix it;
Disable persist so no catching up on missing scripts. Set OnBoot=5m so it gets ran 5 minutes after boot, so your script (say backup) is ran on boot first, then every time on schedule
Enable persist but just add sleep in ExecStartPre - very "cron" way but there is just no in-systemd option to enable "catch up" script to be delayed
Sadly no option to "run catch-up timers with delay" at least yet
> Then don't use @hourly, use staggered times, it's very easy.
Not in cron. In systemd it's just RandomizedOffsetSec=30m and it is "stable" - same host with same job will always have same delay so on multiple hosts it is spread nicely. There is also non-stable version
Re: Love systemd timers
#136Earlier 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.
Sure, I'll pile on here. To do nontrivial scheduling you'd use the entirely-obvious-and-intuitive syntax described at [0]. For example:
Mon,Fri *-01/2-01,03 *:30:45
[0] https://www.freedesktop.org/software/systemd/man/latest/syst...>
[1] This question is sarcasm. SystemD is often like this... dead simple things look dead simple, but complex things are -if they're possible at all- at least as complex as they are everywhere else.
Re: Love systemd timers
#137I've converted all my crons to systemd timers+services over the past year but cant help but think it's sort of.. less tangible than cron Like imagine trying to explain systemd timers and services and unit files to a beginner.
cron is easier for easy stuff ("just run this every 10 minutes") but harder for hard stuff ("run it every 8 hours but with randomized offset so not all machines at once do it, but also if machine was down when it should run, run it immediately").
It is also easier to debug as every job gets its own log rather than trying to write to system mailer nobody had set up with the job errors
Re: Love systemd timers
#138Earlier 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.
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".
Re: Love systemd timers
#139And 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.
Re: Love systemd timers
#140Earlier 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.
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…
Yeah, it would be nice to have a folder like /etc/systemd-jobs/ where I could put them and where there are no files unrelated to job scheduling. There is /etc/systemd/user, but it does get a bit of pollution depending on the system.