{"id":13710,"date":"2015-03-25T05:06:18","date_gmt":"2015-03-24T18:06:18","guid":{"rendered":"http:\/\/www.rjmprogramming.com.au\/wordpress\/?p=13710"},"modified":"2015-03-25T05:06:18","modified_gmt":"2015-03-24T18:06:18","slug":"linux-crontab-considerations-tutorial","status":"publish","type":"post","link":"https:\/\/www.rjmprogramming.com.au\/ITblog\/linux-crontab-considerations-tutorial\/","title":{"rendered":"Linux crontab Considerations Tutorial"},"content":{"rendered":"
\"Linux<\/a>

Linux crontab Considerations Tutorial<\/p><\/div>\n

The crontab<\/a> functionality in Linux or Unix is just great. It is batch processing<\/a>, doing things while you are not there.<\/p>\n

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?<\/p>\n

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

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”?<\/p>\n

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<\/a>), and show:<\/p>\n

    \n
  1. an interactive run … via command line .\/basegetmelist.ksh<\/i> … using our basegetmelist.ksh<\/a> … containing …
    \n
    \n#!\/bin\/ksh
    \nfind \/Applications\/MAMP\/htdocs\/ -name '*GETME' > \/tmp\/basegetmelist.wis 2> \/dev\/null
    \ncurl http:\/\/localhost:8888\/getmelist_localhost.php
    \nexit
    \n<\/code>
    \n\n<\/li>\n
  2. a not ideal crontab scenario (lacking “bulletproofness”) … (ie. what if the “find” command should fail, or run past one minute) …
    \n
    \n45 12 * * * find \/Applications\/MAMP\/htdocs\/ -name '*GETME' > \/tmp\/basegetmelist.wis 2> \/dev\/null
    \n46 12 * * * curl http:\/\/localhost:8888\/getmelist_localhost.php
    \n<\/code>
    \n\n<\/li>\n
  3. a good crontab approach (but not very readable in “crontab -l”) …
    \n
    \n38 12 * * * \/Applications\/MAMP\/htdocs\/basegetmelist.ksh
    \n<\/code>
    \n\n<\/li>\n
  4. a good crontab approach (and very readable in “crontab -l”) …
    \n
    \n34 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\"
    \n<\/code>
    \n\n<\/li>\n<\/ol>\n

    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<\/a> 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”<\/a> thanks.<\/p>\n

    If this was interesting you may be interested in this<\/a> too.<\/p>\n