by As a sole sysadmin for a site whose primary unix-experienced backup is also out of the office this week, I am being fairly easy-going about dealing with user requests through VPN while I am at LISA. Actually, in general I am easygoing about requests that include things users could do themselves, though if they are able to even remotely handle a unix shell I will also tell them how to do the tasks in question. So far, “supporting our environment remotely” has mostly included things like setting up some application management accounts, or investigating small fires.
This morning brought the following e-mail from the lead developer for said application.
please check if $system is setup to run the Friday night cron job that runs $application data extract. This job uses SQL*Plus to run the $jobname database stored procedures in the $foo. The cron job should be the same as what is running in production on $system2 (except that it should connect to $db1 instead of $db2). If possible I would like this cron job to run in the $bar environment this Friday..
After a moments thought (the time it took a fuzzy underslept brain to register that this was not a request that required my assistance), I wrote back with instructions on how to list and edit cron entries, as well as suggesting two members of the same development team who use cron regularly and could help him if he got stuck. I’m now hoping this won’t turn out to have been a bad idea. After all:
Give a man a cron, and his job will run once a week for the rest of his life. Teach a man to cron and he can bring the system down to a grinding halt in minutes.