2 ms·

As much as I don't want to, I have to admit you have merit here on all points. My question though: how did we manage to run infrastructure using cron for decad

As much as I don't want to, I have to admit you have merit here on all points. My question though: how did we manage to run infrastructure using cron for decades and did not feel any of that pain? My take on the answer is this. Failures: we have /var/log/something for this and typically it's obvious something is not being executed. Many files: yes, there are different configs but don't you remember where you typically put your cronjobs? For example I always use user's crontab, so this is where I would look for the job spec. Dependency check is one of the main reasons for systemd as PID1 if not the main, so hands down, that's valid and true.

akerl_ 2y ago
We did feel pain. You could mitigate the pain by never making mistakes (like by ensuring all your cron scripts log to somewhere in /var/log, or that you have alerting, or that you always put them in crontab). But also what we consider to be painful has evolved. When all systems were to some extent a hand-gardened entity, maintained by some specific system administrator, it was easier for them to have a personal standard. It didn't matter if I used cron.d and you used crontab, as long as on our own systems we kept one method. Increasingly, servers are more ephemeral, more horizontally scaled, and more automated, and systemd timers are just easier to work with in that model. In a decade or so, I'm sure we'll have further modified how we handle systems, and something else will come along that solves painful things about systemd.