Linux crontab Considerations Tutorial

Linux crontab Considerations Tutorial

The crontab functionality in Linux or Unix is just great. It is batch processing, doing things while you are not there.

This same crontab strength is also, at times, a source of its weakness … what if something goes wrong (and … doh … you won’t be there)? What if one process relies for its input on the successful completion of another process, and that process can occasionally fail, for some odd reason, or runs longer than expected?

Well, even if this can happen, and you haven’t catered for every eventuality in the scripting (we’re using Korn Shell scripting today) there are some better “approaches” to this, (in contrast to some other approaches), with regard to your “crontab” usage design considerations.

Before we get to that, though … why would it be that “you haven’t catered for every eventuality”? Well, the usual situation is that the code to cater for “every eventuality” would make your code hundreds of times bigger than you first thought, and think practicalities should come into play here, and assess programs on a risk analysis basis … ie. is it the end of the world if this process very occasionally fails, or displays data that is old but “true”?

Okay, today we are simulating on our http://localhost:888/ MAMP Linux web server, something like the rjmprogramming.com.au domain does with respect to its “All Posts” “Code Download Table” (we talked about with PHP Blog Summary Follow Up Tutorial), and show:

1. an interactive run … via command line ./basegetmelist.ksh … using our basegetmelist.ksh … containing …
   
#!/bin/ksh
find /Applications/MAMP/htdocs/ -name '*GETME' > /tmp/basegetmelist.wis 2> /dev/null
curl http://localhost:8888/getmelist_localhost.php
exit

   
2. a not ideal crontab scenario (lacking “bulletproofness”) … (ie. what if the “find” command should fail, or run past one minute) …
   
45 12 * * * find /Applications/MAMP/htdocs/ -name '*GETME' > /tmp/basegetmelist.wis 2> /dev/null
46 12 * * * curl http://localhost:8888/getmelist_localhost.php

   
3. a good crontab approach (but not very readable in “crontab -l”) …
   
38 12 * * * /Applications/MAMP/htdocs/basegetmelist.ksh

   
4. a good crontab approach (and very readable in “crontab -l”) …
   
34 12 * * * ksh -c "find /Applications/MAMP/htdocs/ -name '*GETME' > /tmp/basegetmelist.wis 2> /dev/null ; curl http://localhost:8888/getmelist_localhost.php > /tmp/ok.ok 2> /tmp/notok.notok"

   

There is another approach that would be to make the “find” functionality happen in the “curl” PHP, and that is okay, but there is an argument to say that PHP exec usage can be overplayed, and of course we lose that obvious “crontab -l” readability of that last idea above. Such approaches to crontab jobs can help you sleep at night, in that if something fails, at least something a bit dumb is less likely to be the end result displayed. We don’t want too much “Dumb and Dumber” thanks.

If this was interesting you may be interested in this too.