I think this article is fine for people that use Linux causally and personally such as their gaming machine or perhaps daily driver. For those that have to support Linux across a wide range of commercial applications I would suggest also knowing how to use cron.
Ambiguous $PATH settings make cron script execution difficult to predict.
For what it's worth one can explicitly set the "${PATH}" or any other variables in a script or include a global variable file.
stdout and stderr output often ends up in a black hole (and, often, sent to the host's mail system, which is usually not what you want to happen.)
That is due to a misuse of cron. There are examples of how to configure cron jobs correctly and how to direct each type of output.
Execution history is difficult to follow and interrogate.
I look to standards or variations thereof suggested by NIST and CISA for custom auditd rules to determine whom executed what and how. This data goes to a local syslog spooler and then forwarded over TCP/TLS to a centralized cluster of syslog and Splunk servers. Rsyslog can be configured to nullify known-knowns to save on storage and processing costs. Be careful setting auditd configuration to be immutable until your rules have been properly battle hardened over time.
Incidentally, timers solve all these problems (and more.)
This makes the assumption every system will have systemd. This may not be the case. I could walk into a company that has a mix of Linux with Systemd, Linux with an alternate to systemd, Linux without systemd (such as Embedded/IoT Manufacturers and Industrial plants, HPC, specialized vendor appliances out of warranty a myriad of which I have had to support), BSD, UNIX or who knows what else. For what it's worth there are cheat sheets that help one understand the time formatting. Some people even put a sub-set of said cheat sheets in the cron header itself. Or one can ask AI to generate a highly customized cron entry based on their requirements.
Bender•39m ago
Ambiguous $PATH settings make cron script execution difficult to predict.
For what it's worth one can explicitly set the "${PATH}" or any other variables in a script or include a global variable file.
stdout and stderr output often ends up in a black hole (and, often, sent to the host's mail system, which is usually not what you want to happen.)
That is due to a misuse of cron. There are examples of how to configure cron jobs correctly and how to direct each type of output.
Execution history is difficult to follow and interrogate.
I look to standards or variations thereof suggested by NIST and CISA for custom auditd rules to determine whom executed what and how. This data goes to a local syslog spooler and then forwarded over TCP/TLS to a centralized cluster of syslog and Splunk servers. Rsyslog can be configured to nullify known-knowns to save on storage and processing costs. Be careful setting auditd configuration to be immutable until your rules have been properly battle hardened over time.
Incidentally, timers solve all these problems (and more.)
This makes the assumption every system will have systemd. This may not be the case. I could walk into a company that has a mix of Linux with Systemd, Linux with an alternate to systemd, Linux without systemd (such as Embedded/IoT Manufacturers and Industrial plants, HPC, specialized vendor appliances out of warranty a myriad of which I have had to support), BSD, UNIX or who knows what else. For what it's worth there are cheat sheets that help one understand the time formatting. Some people even put a sub-set of said cheat sheets in the cron header itself. Or one can ask AI to generate a highly customized cron entry based on their requirements.