Also, lots of operators have decades of experience with cron, and don't want to give up on that easily.
[Update] After reading https://wiki.archlinux.org/index.php/Systemd/Timers I see two more reasons
* You don't have to write a service file to use cron jobs, which makes ad-hoc tasks much easier
* Sending mails is the default for cron, which requires extra work with systemd.
But, to be honest, writing crontab is easier task, systemd timers are not more intuitive than cron when you write them, i.e. I personally still look in documentation for various systemd options, but are IMHO much easier to read and more powerful, and have great "systemctl list-timers" view, but unfortunately not superset of crontab options. That's probably the second reason to still use crontab.
I like /etc/crontab. It is a simple text file. Nothing magic. Standard. Works every time. Well known by everybody. Works on a lot of UNIXes, old Linux systems etc.
I don't want no new complexity and a new way to do things every 6 months. What I hate most is that all this is pushed through our throats no matter what we want. FFS.
EDIT: BTW, I think luckily, /etc/crontab at least currently still works on Ubuntu Server 16.04 (what I've tried). I think this is the way to go. If you want to use some new features (systemd) you can opt-in. But don't break old stuff please.
Here's what I'd call a simple init.d-like example. non-needed things (if you think it's too complex) include: wait for fs mount and network, custom reload command, "don't log stdout"
[Unit]
After=network.target
AssertPathIsMountPoint=/mnt/service-data-if-needed
[Service]
ExecStart=/some/binary
Environment=CONF=/etc/i/guess.conf USER=nonrootmaybe
ExecReload=/bin/pkill binary
KillMode=process
Restart=always
StandardOutput=null
[Install]
WantedBy=multi-user.target
EDIT: man 5 systemd.unitIf we're comparing running a binary on startup vs. setting it up as a service in systemd, I wholeheartedly agree that you should always use the right tool for the job. So let's discuss the software, not the politics :)
If we're talking about the original story (crontab) people should compare it to systemd timers if they're looking for alternatives - which I still prefer.
I have no stake in OSes choice of default installed packages (be it init, openrc, or systemd), and agree with your parent comment that OSes shouldn't break (dropping crontab as an installed base package) without consideration.
I haven't come across one of these OSes where it wasn't possible to install crontab from their default package managers, and in their main repositories, though.
About the timers in systemd I haven't even look at them. As long as I don't need them I'm fine with 'cron' and 'at'. Maybe they are not the best posible systems, but IMO work quite well (and I don't have to change my code to use them). If at some point I encounter problems or limitations with my uses of cron and those are fixed by systemd I will happily update to systemd timers. For now the work perfectly fine for my needs.
That only guarantees that your network devices have been enumerated, not that they are available with assigned addresses.
I encountered this problem with SSH failing to start on Ubuntu 16.04 server. systemd was launching SSH before the binding address had been assigned, causing SSH to abort and fail and the server to continue to boot without any way of accessing it remotely.
Workaround ( at the physical console ) was to add a Retry to the SSH unit and time it to coincide with the address having been assigned[0]. hacky, but no other unit imperatives worked.
[0] Default behaviour in the SSH unit, at least on Ubuntu, is that it tries once and never again.
Also, i expect the faithful to come and claim it is a Canonical fuckup.