No need to do a man crontab here



  • Unbeknownst to me, there was a problem with one of the transaction processors cron jobs.  When my colleague called their technical support to get the problem resolved, they immediately pointed the finger at my faulty server configuration.  "Apparently, the bats user on that machine doesn't have cron privileges", I hear the support person say over phone, "And I know it's not the cron because it works on everybody else's server.".  Anything's possible so I logged in as root and checked my cron.deny file.  Nope.  So I su'd to the user bats and ran the following:

     

    -bash-3.00$ crontab -l
    ## BATS
    */15 * * * * cd /var/www/bats/www/signup; /usr/bin/php cronjobs.php;
    ## BATS
     

    Figuring everybody's gotta eat, I decided to post it here instead of in an email to the support person's supervisor.

     



  • What's wrong with that?



  • They're trying to run cd which if called from system or exec or anything like that actually does nothing; also they are relying on bash's command seeprator (semi-colon) when exec by default uses sh which does not have that feature (and bash doesn't allow it when emulating sh which it will if sh is a symlink to bash iirc).



  • @Lingerance said:

    They're trying to run cd which if called from system or exec or anything like that actually does nothing; also they are relying on bash's command seeprator (semi-colon) when exec by default uses sh which does not have that feature (and bash doesn't allow it when emulating sh which it will if sh is a symlink to bash iirc).

    So you're saying that the line "cd /home/mark/removebot && ./removebot.pl > /dev/null 2>&1" from my crontab can't possibly be working?



  • @Lingerance said:

    They're trying to run cd which if called from system or exec or anything like that actually does nothing; also they are relying on bash's command seeprator (semi-colon) when exec by default uses sh which does not have that feature (and bash doesn't allow it when emulating sh which it will if sh is a symlink to bash iirc).

    I have /bin/sh symlinked to bash and semicolons work fine.



  • @Carnildo said:


    So you're saying that the line "cd /home/mark/removebot && ./removebot.pl > /dev/null 2>&1" from my crontab can't possibly be working?

     

    No, that will work, as you know well.  "cd /home/mark/removebot; ./removebot.pl > /dev/null 2>&1" will fail.



  • @Lingerance said:

    They're trying to run cd which if called from system or exec or anything like that actually does nothing; also they are relying on bash's command seeprator (semi-colon) when exec by default uses sh which does not have that feature (and bash doesn't allow it when emulating sh which it will if sh is a symlink to bash iirc).

    Cron does not exec the command directly or use system, it passes the entire thing as a string to $SHELL -c (which you can modify from within crontab). Here's the relevant code from vixie cron:

                             char    *shell = env_get("SHELL", jobenv);
                            execle(shell, shell, "-c", e->cmd, (char *)0, jobenv);



  • Different programs do different things, all I knew was certain versions of exec actually call sh and semicolons in my experience do not work, why it works for you guys is beyond me, I copy the command I'm trying to run into a bash shell script and all is good.



  • @Lingerance said:

    Different programs do different things, all I knew was certain versions of exec actually call sh and semicolons in my experience do not work, why it works for you guys is beyond me, I copy the command I'm trying to run into a bash shell script and all is good.

    You wouldn't be one of my saner colleagues who run *BSD, would you? Many linuxes (linii?)  use bash as the default shell, so their crontabs may have all of bash's extensions available. As BSD's base shell is sh, it would not.

     Anyway, anyone sane puts their commands in a .sh file when using crontab, don't they?

    (First person to say that The Real WTF is using BSD had better be wearing asbestos undergarments.)
     



  • Wrong, it's always executed with "sh -c", so semicolons should be working, but are extremely bad style and && is to be preferred at any time.

    One of our admins at university actually did the semicolon mistake there... and it ended up as a gaping security hole and we had to reinstall the server. In crontab, there was:

    42 * * * * root cd /var/spool/mail; find . -type d -exec chgrp mail {} ; -exec chmod 777 {} ;; find . -type f -exec chown mail {} ; -exec chmod 664 {} ;

    This line worked for over five years, and we today have no idea who originally wrote it and why this was even needed.

    But one day, we tried brie. The NFS server connection broke down "a little", resulting in the "cd /var/spool/mail" to fail... and it did all the chowning and chmodding in /, that is, on the WHOLE file system! Luckily, the connection to the NFS server with the user data was down too, so "only" the whole system got chowned and chmodded, user data was unaffected.

    This is why you should NEVER use cd in conjunction with semicolons. ALWAYS check if a cd worked. 



  • @robbak said:

    Anyway, anyone sane puts their commands in a .sh file when using crontab, don't they?

    No, for short commands most sane people just put "SHELL = /bin/bash" at the top.



  • Why should that be needed for short commands? /bin/sh is a POSIX shell and has to understand ;. /bin/csh... sucks, but still understands ;.



  • No, the point is for long commands you should put them in a script instead of putting them all together in one line. The idea that sh doesn't understand ; has already been debunked, the problem was that ; does no error checking.



  • @robbak said:

    (First person to say that The Real WTF is using BSD had better be wearing asbestos undergarments.)

     

    The Real WTF is using BSD.

     

    LOL just kidding.  I actually don't care.  Use BSD all you want.  I won't mind. 


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.