Somebody tell me why I shouldn't use systemd timers, as opposed to crontab entries. Because I've been very impressed with them, so far.

systemd timers have the disadvantage that they also work properly when the machine wasn't running the moment the timer hit. That means you will not be hunting missed cronjobs anymore, but who would want things to just work?

@Fast-Nop

WHERE'S MY CONFIRMATION EMAIL

May I ask where this question stems from?

I'm not a fan of SystemD at all, but this has more to do with architecture and certain persons....

SystemD Timers solve a lot of nightmares cronjobs have.

Especially as they can form dependency chains, e.g. to a mount service / a requirement to network-online and so on.

Other important thing is the handling of environment files and security limitations.

As a systemd timer is bound to a systemd unit, you have a whole lot of goodies that you usually had to deal with seperately...

E.g. checking if certain files for env config exist, ensuring ULimits settings and so on.

I understand systemd hate for many things, but timers are really awesome.

@IntrusionCM

Yeah, I was dragged kicking and screaming into the systemd world, and I fought it for years. What really made me re-evaluate my resistance was Arch Linux. Debian and especially Ubuntu really work hard, in my opinion, to obscure/abstract systemd from the user, even though they are 100% on board now with it. Diving into Arch as I did in 2019, I was forced to deal with it more, and learn more about it. I'm not totally onboard with it today, but I at least see what they're going for: a cohesive system underpinning for which the myriad modular components share a uniform arrangement and syntax. As a sysadmin by history I can definitely respect that, and I really hope they get there.

I recently built a new desktop, and as I was installing Arch on it, I realized that there was no cron in the base install. Several flavors are available, but the wiki presents them in a kind of, "if you absolutely must use cron, Uncle Oldman..." tone. I had been meaning to look into systemd's scheduler, but had never gotten around to it before. So I dove into it last night, and I feel like a fool for not having done it sooner.

I've already converted a data population crontab entry on one of our task runner VMs at work to use a user-based systemd timer, and it's working brilliantly. I'll be making a repo on our github enterprise server just for service and timer files for these.

@bahua Yeah...

The general intent of SystemD is good.

But i really really really hate that they didn't even bother to keep the Unix philosophy alive.

Do one thing and do it well.

They're creating a ful OS framework that is absolutely not modular.

You cannot just have systemd.

You have systemd, logind and all the other stuff...

Architecture wise, I think this is the ultimate level of shit.

Well... Debian struggled with it for obvious reasons - Debian tries to be the Swiss.

And as Ubuntu is just Debian with another name sprayed on it... ;)

I'm a bit terrified of SystemD still.

If the systemd team decides to go bananas, this will be a major pain in the arse...

@IntrusionCM The problem here is that the Unix philosophy ran face first into a complexity wall.

See it this way: nobody except Poettering likes systemd's sprawling nature - yet most distros made the change. So either most distros are maintained by idiots, but in this case, that would already have become total shit long before systemd. Or, if we rule that out, the status quo before systemd was even worse.

And it was - because the zoo of scripts trying to orchestrate a shitload of things including potential error handling was no less complex, but you had to model dependency chains yourself.

@Fast-Nop Yes.... No... Maybe....

It's more than Poettering in SystemD.

The status quo before SystemD was that every distribution did it's own thing, which was bad.

Most promising was e.g. upstart, which even landed in Fedora / RedHat.

... And is dead now.

OpenRC is still alive and well. And has a lot of the features people missed. Especially dependency management.

The reason SystemD became so popular is simply because it had RedHat as it's main support...

And it solved one problem that still exists in many forms in many distributions: shell scripts are a PITA to support.

Be it BASHisms, lack of recent version of Bash, required POSIX compatibility or <insert tons of reasons here>.

I'm not unhappy with SystemD.

But (and this does not apply to Lennart only) there are many persons in the SystemD / DBUS / ... teams I just cannot agree with...

And I don't think the Unix philosophy hit a wall.

E.g. microservices are exactly that.

What was... And still is... A major pain.... Distributions working together.

Till today every distribution tries to solve everything on their own - a real cooperation doesn't exist.

I could now scream for 4 h and more of examples, but I'll make it short: The Unix philosophy is valid.

But when every distribution keeps up it's patriotism and "we do this differently here" way, then yeah.

Things like systemd will always win.

I really wish that the feudalism (or whatever you call it) would stop.

@IntrusionCM The fragmentation argument doesn't really work though because then, Redhat supporting systemd should have lead to just more fragmentation, i.e. systemd staying a Redhat thing. It doesn't explain distros having changed that aren't downstream of Redhat.

Or, if the argument is that Redhat is so powerful that they forced everyone into their ways, then why hadn't everyone just been using Redhat's script zoo before?

The logical explanation is that it sucked more before. I mean, even basic questions like "why does my boot take so long" were not exactly easy to answer.