Separating the schedule from the process might be an annoyance to newcomers... But I promise it's worth it
It's two files to template instead of one line, but it fixes essentially every lesson we all learned with cron. $PATH being incomplete, locking, etc
Another nice benefit is dependency handling.
If your 'cron job' requires networking you have to write boilerplate code or let it fire/fail endlessly. Pray the processes don't linger/stack or otherwise make a mess.
If a timer needs networking, set After= and Requires= to networking.target or whatever is appropriate for your distribution - and you're golden.
Even better if the job acts against another actual systemd service.
Using systemd-networkd you can tie the timers to specific interfaces. [but this handles NAT weirder than you're probably used to, if a host acts as a router prepare to adjust]
Separating the schedule from the process might be an annoyance to newcomers... But I promise it's worth it
It's two files to template instead of one line, but it fixes essentially every lesson we all learned with cron. $PATH being incomplete, locking, etc
Another nice benefit is dependency handling.
If your 'cron job' requires networking you have to write boilerplate code or let it fire/fail endlessly. Pray the processes don't linger/stack or otherwise make a mess.
If a timer needs networking, set After= and Requires= to networking.target or whatever is appropriate for your distribution - and you're golden.
Even better if the job acts against another actual systemd service.
Using systemd-networkd you can tie the timers to specific interfaces. [but this handles NAT weirder than you're probably used to, if a host acts as a router prepare to adjust]