💾 Archived View for thrig.me › blog › 2024 › 10 › 27 › cron-soon.gmi captured on 2024-12-17 at 10:42:06. Gemini links have been rewritten to link to archived content

-=-=-=-=-=-=-

Run a cron job, soon

    < rahl> Is there a way to test e.g. weekly.local?
    < ssm_> if you want to see if weekly runs it, you could
            sh /etc/weekly I guess

This may not be good advice; cron jobs may require a different environment than is set by a random user shell process (with who knows what set from who knows where), or may assume a different working directory. Choices here are to:

Run `sh /etc/weekly` and to hope that any differences from the crontab environment do not cause any problems. As you might be able to tell, I am not a fan of such faith-based job execution, as it usually has fallen to me to cleanup after such issues, and I was usually working in a risk adverse environment: what could possibly go wrong if we run a payments job incorrectly?
Review all the code involved to see if anything relies on a particular working directory or environment variables set by cron(8), or whether the whole mess can be safely run standalone. Maybe there is also session foo or security context bar to worry about? Does the job only run from cron, and tickles a linux kernel bug otherwise?
Use a script that generates a cron job to be run "soon" from cron. That is, within a few minutes on the current (or next, for rollover cases) day.
Other?

    $ crontab -l
    ~ * * * * /home/jhqdoe/libexec/syncmail
    $ kronsoon /home/jhqdoe/libexec/syncmail ; date
    36 23 26 10 * /home/jhqdoe/libexec/syncmail
    Sat Oct 26 23:35:17 UTC 2024

A downside is that you need to remember to remove the test crontab entry; I never really felt the need to automate that part. With configuration management you could clobber the crontab file to what it should be (thus erasing any test entries) or to have a diff reported somewhere for review (that people may not get, read, nor understand). The test job runs at most once per year (unless a Daylight Savings Time repeat is there to ruin your day, or the system clock gets changed) so that's hopefully enough time to clean it up. Presumably when testing a cron job you're right there and can even have a todo item to remove the entry if your job is prone to interruptions and distractions.

You may also want to check whether jobs are safe to be run at unscheduled hours; this is probably okay for a job that cleans up random working directories, but maybe not okay for a payments job that is required by contract to run within a particular time window, once. Such requirements might best be put into the code so that the script fails with a message if it is run too soon or at the wrong time. So there may be some amount of "understand what all this code does" especially if the previous maintainers did not document those details, or if the details got lost. One example of this is if there has been heavy developer turnover, and some sysadmin are brought in to support and figure out how the environment works (or does not, as heavy developer turnover may not result in a particularly well-run environment).

Scripts can be written to run standalone, but that might result in environment settings being duplicated across who knows how many scripts rather than once in the crontab file. Or, you might instead go with a wrapper script that sets up the environment? Having one place where any necessary environment customization is done can be nice.

    #!/bin/sh
    cd /somewhere || exit 1
    export FOO=bar 
    . more-env-here
    exec real-script "$@"

As an example of environment variables gone wild, Mailman used to sometimes barf weird error messages; these appeared because the web guy had done a SSH from his macbook and had carried along some wacky environment variables that mailman objected to. Worse, the errors did not go to the web guy when he ran whatever, but appeared as an email to me. This made tracing down where the errors were coming from a bit harder: what the heck, mailman, you didn't have a cron job around that time, so how the heck…

P.S. do not schedule time sensitive cron jobs (payment batching, for example) anywhere near the hours of Daylight Savings Time wobbles. I'm more a fan of putting the servers into UTC to avoid that whole mess, but this can create other problems, like when other humans expect timely notifications in a local timezone that does wobble randomly. Weird, right?

P.P.S. various implementations of kronsoon can be found in

https://thrig.me/src/scripts.git