261–270 of 309 posts
systemd is great all around. Don’t listen to the boomers complaining about it because their cheese was loved.
Earlier quoted context omitted.
> 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.
Total n00b here. My first linux install was pretty recently, in late 1996 or early 1997 (sometime that winter). I just don't get it. Like is the core sentiment "How dare they address obvious system shortcomings"? Is it "I learned once and how dare you think I'm capable of learning again"? Is it "I want others to suffer the way I did to learn job scheduling"? cron did a job, but had shortcomings. Systemd addresses man…
I'm all for it.
However the trust in systemd brand and its leader is deeply negative, so anything that comes from systemd folks is an immediate no.
>And yet. You probably shouldn't use literal cron (or its more modern cousins) for scheduled tasks! In 2026 there are more modern options available What are people on non-systemd distros like Guix System, Void, PCLinuxOS, and so on using for this? Is there still something better to use than cron? Admittedly I never learned cron, I use a lot of `sleep` and `countdown` for relative delays instead. Just earlier today I…
We have used and still use cron for decades. It does it's job and does it well.
You will love SystemD [0] timers until they fuck you over in an entirely inscrutable way and the SystemD maintainers don't care to either fix the problem or update the docs to warn of the shortcoming. One of our customers called in with a production down incident caused by a full disk. We got a copy of the VM and took a look. Investigation revealed that / was full because /var/log was full and that our 'logrotate' ti…
Earlier quoted context omitted.
XML would have the advantage of having a grammar so we could validate the config files. It would also make it much simpler to make good GUI editors for the files instead of the Notepad approach most unix config files take.
The systemd dialect of INI is actually pretty well-defined though. https://www.freedesktop.org/software/systemd/man/latest/syst...
E.g. in "Section C" the resulting KeyThree is "value 3▵▵▵▵▵▵▵value 3 continued" where each "▵" symbol is a space.
I think most people would expect a single (or no) space here.
I would guess that most software would strip the comments in SectionC or rearrange the output so that it will result in a diff even when nothing in SectionC changed.
So if you edit the file by hand in the same style as shown in the examples, then most editors would not be able to make a minor edit without making a large diff as many sections would be formatted differently.
Earlier quoted context omitted.
I found the systemd time spec syntax you referenced to be logical and well thought out. Cron syntax is simpler for the easy cases because cron tries to do less. It ignores years and seconds entirely, and doesn't try to adhere roughly to ISO8601 ordering and field separators, instead using space universally for field separation and euro-style least-to-most significant field ordering. I like ISO8601, so I get along wit…
> But good luck doing that in one line in cron. Two options: 0 0 25-31 5 1 or, if your cron supports „L“: 0 0 L 5 1
At least busybox's cron implements it that way:
if (line->cl_Mins[ptm->tm_min]
&& line->cl_Hrs[ptm->tm_hour]
&& (line->cl_Days[ptm->tm_mday] || line->cl_Dow[ptm->tm_wday])
&& line->cl_Mons[ptm->tm_mon]
) {Earlier quoted context omitted.
> But good luck doing that in one line in cron. Two options: 0 0 25-31 5 1 or, if your cron supports „L“: 0 0 L 5 1
The first one works in that specific case, but not more generically. For example, "Last Monday in February", or "last Monday of the month" for multiple months unless they're all 30 or all 31 days.
# Run a command on the last day of the month. Only starts checking at midnight towards the end of the month. Assumes GNU date, which is fair if we're discussing a Linux-only cron-alike.
0 0 28-31 * * if [ $(date +\%d) -eq $(date --date="$(date +\%m)/1 + 1 month - 1 day" +\%d) ]; then /usr/local/bin/runCommand.sh; fi
If I were doing this for real, I'd either switch to a more capable cron, or take a serious try at the date math and then wrap it up as a standalone helper. Or I guess I'd look to see if someone already built that helper. ...I guess...
Earlier quoted context omitted.
> What makes you say that? You can set the PATH right in the crontab. OK but I don't want to hardcode $PATH in the crontab just so I can test the cronjob. Barring the hardcode, $PATH is one thing when cron runs and another when you try out the command yourself. systemctl start foo.service starts the command inside with the same environment as when the timer fires so you know it'll work the same. On the flip side, you…
> $PATH is one thing when cron runs and another when you try out the command yourself. Why would that be different with systemd timers? If my ~/.bashrc adds /opt/foo/bin, that's also not part of the systemd timer's PATH, right? But I guess you're saying the ability to trigger the systemd timer off-schedule is the difference? Yeah, it's annoying with cron to have to temporarily set the trigger two minutes into the fut…
>Not sure adding that feature justifies a complete rewrite, but certainly a nice addition.
If there is a feature that justifies using a completely different tool it's obviously this one.
Earlier quoted context omitted.
This is such a modern view. People used to HATE systemd when it first came out, but I always liked it and knew people would eventually come around and its nice to see they finally did!
People still hate systemd First it caused lots of issues. And didn't deliver anything significant But the biggest issue has always been architectural, the way systemd keeps absorbing existing projects, and functionality. That keep adding to the more than 1 million lines of C monolith, that can burden progress in the futre But as long people can replace any of systemd tool, for a tool they like better, all good Person…
Earlier quoted context omitted.
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 Who'd ever want to go back crontab format for nontrivial scheduling? [1] [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 thi…
For cron, despite years of looking at it, I can never remember what those numbers mean and I need to Google almost every time.