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.
Love systemd timers
111–120 of 309 posts
Re: Love systemd timers
#112systemd is complex on first view, but after using it you didn't want to use anything else. It's handy to manage everything using systemctl
I hard disagree. Previously I could use what I knew about Linux commands to read logs and administer the systemm. Systemctl knowledge does not generalize.
I have done scheme all my life, which is why I prefer shepherd. Not only is it in a syntax that i can use elsewhere, I get completion in Emacs.
Re: Love systemd timers
#113Earlier 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.
Cron also has @reboot. Not exactly the same, but has been sufficient for me so far.
Re: Love systemd timers
#114We 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.
Thank Lennart you degenerate apostates are finally starting to see the light of His glorious creation. Hallowed be thy systemd-journald.
Re: Love systemd timers
#115That would assume I like systemd in the first place.
Re: Love systemd timers
#116Earlier 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.
$ systemctl cat public-inbox-watch@.timer
# /etc/systemd/system/public-inbox-watch@.timer
[Unit]
Description=Periodic fetch of public mailing list
[Timer]
# twice a day
OnCalendar=*-*-* 5,17:35
RandomizedDelaySec=1h
Persistent=true
[Install]
WantedBy=multi-user.targetRe: Love systemd timers
#117I 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…
> 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.
Re: Love systemd timers
#118Does systemd ship with something to upgrade your cron jobs for you? That would be the friendly way. Write your old school cron jobs, and then a script that converts them to do things the systemd way, documenting its steps, i.e. I created this file and this is why. Friendly "I help you do things better" rather than standoffish "your way is obsolete, you need to do it our way". Oh wait. I get it. LLM agents can do exactly that for you can't they. Another way I'm behind the curve.
I have knocked together a systemd service or three based on google copypasta. But generally, for cron jobs, why make it complicated? One line in /etc/crontab and done. I generally call an encapsulation script that sets the right environment variables, uses absolute paths, captures stdout/stderr if required and so on. I just want the simplest possible way to launch that script on a schedule.
Re: Love systemd timers
#119Earlier 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.
Something like:
OnCalendar=00/6
systemd-analyze calendar --iterations=6 '0/6:00:00'
https://www.freedesktop.org/software/systemd/man/latest/syst...
Re: Love systemd timers
#120I 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…
> 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`? ;)