Cron not working?



  • Hi there,

    I added a job using the crontab -e command as root. The jobs do not get executed. Why is that?
    If I run the command manually, everything is fine…



  • Is there any other way besides downloading the config, editing it, uploading it again and rebooting the device?



  • Any1?



  • You'r right. I have a job in which isn't executed too. Looks like an error. System-cronjobs are executed.
    Is it failure of the cron-package or system-error?



  • You can't edit crontab to add jobs. Put them in the config.


  • Rebel Alliance Developer Netgate

    You can also install the Cron package which gives you a nice gui to maintain the cron jobs (system and user added ones)



  • I'm having the cron-package installed and my cronjob is in the config.xml, but not executed. MAnually it works great, but not automatic.


  • Rebel Alliance Developer Netgate

    The most common other error with scripts that don't work in cron is not using full paths to all files and programs being used.

    The way cron scripts are executed they don't inherit much of any environment settings, especially PATH, so if you run something such as "grep" in a cron script you really need to use "/usr/bin/grep" instead.



  • I know about this problems, and my script is calles directly with full path. The script itself uses full path all time. No indirect references used. So this errors are not possible. Calling the script via console works great.



  • Missing execute bit on the script?


  • Rebel Alliance Developer Netgate

    @_igor_:

    I know about this problems, and my script is calles directly with full path. The script itself uses full path all time. No indirect references used. So this errors are not possible. Calling the script via console works great.

    I suggest you check your script again, or if it's something you can share, post it so others can try.

    I just verified that a basic script does, in fact, work with cron for me on a 2.0 box.

    cat test.sh

    #!/bin/sh 
    /bin/echo blah >> /tmp/blah.txt

    chmod a+x test.sh

    ./test.sh

    cat /tmp/blah.txt

    blah

    Add cron job via Cron package GUI:
    */1  *  *  *  *  root  /root/test.sh

    wait… wait... wait...

    cat /tmp/blah.txt

    blah
    blah
    blah



  • Hi,

    I have a cron job which is not executed in the build 05/04/10 of 2.0….

    30 * * * * root /usr/bin/nice -n20 /etc/rc.conf_mount_rw ; /usr/bin/tar -czf /cf/conf/rrd.tgz -C /var/db/rrd/*.rrd ; /etc/rc.conf_mount_ro

    This line actually does work with my 1.2.3 install but not in 2.0

    Any info?


  • Rebel Alliance Developer Netgate

    Does the same line work as-is if you run it from the shell?



  • Yep. Works from shell.


  • Rebel Alliance Developer Netgate

    Did you add this via the cron package, or manually into the config file?

    I wonder if the job is making it into the actual crontab file.



  • Downloaded the config. Edited it and restored it. I can also see this line in /etc/crontab…



  • @jlepthien:

    30 * * * * root /usr/bin/nice -n20 /etc/rc.conf_mount_rw ; /usr/bin/tar -czf /cf/conf/rrd.tgz -C /var/db/rrd/*.rrd ; /etc/rc.conf_mount_ro

    Hi,
    I'm a real pro at screwing up cron jobs on all sorts of machines then blaming Paul Vixie for it instead of myself :)

    Firstly, be careful with the nice-ness part. Something in the back of my head says that you should maybe be using:
    nice +20  command
    to give a nice value of 20 (lowest priority of niceness - ie: very nice)
    and not
    nice -n20 command
    which parses as   nice , with the option " -n " and a value of "20" , where the +sign in front of the 20 is omitted as the number is assumed to be positive rather than negative. The " - " in front of the " n " is merely the option prefix/delimiter/thing.

    BUT I'm probably wrong, because that's how the shell built-in nice works. You're using /usr/bin/nice , so check that (a) it's actually there, and (b) thats the correct syntax you're using for that command you're calling. I think that syntax is correct for the /usr/bin/nice, but check it.  Different nice-s on different OSs and shells can be drastically different in their handling of the -n20 , +20, -20 etc. Also, if you occasionally interchange shell scripts with linux, you may want to prefer the (+)19 niceness value when you write scripts for compatability, not 20, because the linux guys don't have our +20 level. It's a Spinal Tap "these go up to 11" sort of situation.

    I prefer to check my nice-ness sytax in most OSs/shells with something like     nice +20 top   because top has the advantage you can actually see the niceness the job is running at, providing instant feedback. Also,  top uses a fair bit of CPU resources, so it usually appears near the top of the process list anyways, making it fast/easy to see.

    OK, now to my main point:-
    I just want to say that I learned the hard way when executing several jobs on one line with cron on a busy machine, troubleshooting is much easier if you do something like:

    30  *   *   *  *  root    /usr/bin/nice -n20 /etc/rc.conf_mount_rw
    32  *   *   *  *  root    /usr/bin/tar -czf /cf/conf/rrd.tgz -C /var/db/rrd/*.rrd
    34  *   *   *  *  root    /etc/rc.conf_mount_ro

    That gives you two minutes per command to say "what the heck is it doing now???" and "what the heck has it done so far" , for example by running top in another shell, or running mount or ls to see what it's done at each stage.

    You can also create/touch debug files in between those commands, eg  && touch stage1cron.dbgstep
    That way you see quickly what's getting done and what's not. Something like:-

    30  *   *   *  *  root    /usr/bin/nice -n20 /etc/rc.conf_mount_rw  &&  /usr/bin/touch /root/stage1cron.dbgstep
    32  *   *   *  *  root    /usr/bin/tar -czf /cf/conf/rrd.tgz -C /var/db/rrd/*.rrd  &&  /usr/bin/touch /root/stage2cron.dbgstep

    I'd also suggest redirecting any stdout and stderr  from these commands to files so you can debug the success or failure of the commands, then compare them with the output the same commands run directly in a shell, in case there are differences. ( just use command > outfile.cron and compare it with the command run direct form the shell with command > outfile.shell ) Differences usually mean path problems or my fat fingers if I haven't cut/pasted.

    When the debugging is done and I'm all happy, I normally recombine into one long line, (easier to carry across .xml's to new installs) but you could roll them into a shell script (then chmod+x it remember) for neatness. BUT, that means if you do a bare-metal reinstall or move to another machine you need to remember to move the shell script too. Sometimes a one-liner is easier :)

    Finally, I prefer using  &&  rather than the  ; to separate one-liner commands. That's because it waits until the preceding command is exited with no errors before it proceeds to the next, which is sometimes much safer, especially on heavily loaded/slow machines.

    HINT: think about that line for a moment - on a hardware example of :Alix+CF and a fast and short tar job onto a recently-re-mounted-as-rw CF.

    1/ Do you mean to nice the /etc/rc.conf_mount_rw   command OR  nice the   /usr/bin/tar -czf /cf/conf/rrd.tgz -C /var/db/rrd/*.rrd   command at a niceness of 20 ??  Personally, I'd want the mount to happen "normally", but run the tar command with a high/pleasant niceness, not the mount. That is, of course, unless the mount script somehow brings the system to its knees and not the tar?? I Dunno.

    2/ What happens if the mount_rw command doesn't complete before the tar starts (and starts writing/attempting to write to the not-quite-mounted-yet CF)?? You nice-d it so that it will run "slower" (really: _nice_r) then immediately followed it with a processor and filesystem intensive tar command, the ; didn't wait until the mount command/script finished, it just plowed straight on, ignorant if the  mount had completed in time, or even completed at all without an error. Use && between successive, inter-dependent commands to ensure one completes OK before next starts.

    3/ Is the stdout and stderr different between pfsense 1.2.3 and pfsense 2.0beta??

    4/ Is the pfsense 2.0beta installed on older/slower/test hardware - does that make a difference ??
    Especially with the  command ; command ; command   sequence instead of a  command && command && command

    All these are potential gotchas, especially if you tested the commands one at a time (by hand, typing slow) at a user shell, but lumped them into a command1 ; command2 ; command 3  one-liner only when you set the cron job. Cron (+the shell) will rattle through them as fast as it can parse the ";" in there. Maybe using && instead of ; will help, worth a try I think

    If you edit the crontab file yourself, make sure you have a  blank line at the bottom of the file. Careful! That's a blank line at the bottom of the whole file, not just a CR at the end of whatever line you add, that's my (frequent) usual mistake if I edit directly.

    warning - very late night here, insomnia hurts@ nearly 4am, also I'm far from an expert, so check out my suggestions very carefully ;)
    Good Luck,
    Gord

    PS: Linux users - with scripts you need to remember that it's not Bash, it's actually ash, or it's often tcsh or csh or maybe ksh  in a normal **FreeBSD user shell- but root's shell in pfsense is a true /bin/sh (so it's ash-based) (as far as I can remember) - That fact can trip some shell scripts up if you cut and paste them blindly. For cron, the shell that will be used for the cronjobs is usually set at the top of  /etc/crontab - I don't have a pfsense 2.0 box booted up right now but it's certainly /bin/sh in 1.2.3.

    EDIT: please people, if you see any mistakes here, post corrections or suggestions. At first glance my post looks far to convincing for a long 4am confused ramble haha**



  • @jlepthien:

    Downloaded the config. Edited it and restored it. I can also see this line in /etc/crontab…

    well, if you can see it in the /etc/crontab , it should (on a normal system, ie: non-pfsense) be picked up when cron next reads that file, unless there's an error in the /etc/crontab file from a previous manual edit.
    iirc, crontab -e  performs some sanity checking before saving to /etc/crontab , but all sorts of things can go wrong later if you manually edit it.

    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

    all this above assumes that it's Paul's version of cron running on a normal FreeBSD system*, BUT, as CMB said in a few posts above, editing crontabs doesn't work in pfsense, you need to put them in the config (which you have done)

    BTW-My most common bork is omitting/deleting the final blank line in /etc/crontab , fwiw

    G

    EDIT: ok, just a wild stab, after you download the config, edit the cron line into it, re-upload the config, I'm assuming the pfsense config re-loads/semi-automatically? or does it need a manual reload, like "apply changes" in the rules pages to action the new config?? been up all night here, not making sense, sorry

    *it watches the mtime on the crontab files for changes, and reloads them if necessary.



  • Today I looked again and now the cron job works…
    Magically....



  • I have installed BETA4 (20100830) today over the 1.2.3 release version…
    CRON showed up installed twice in 1.2.3 dashboard, so that was quite odd - but it worked just fine.

    After upgrading, CRON appears to be started, but the GUI is inaccessible...

    Reinstalling package or GUI only gives me "Loading package instructions... Deinstall commands..." - and then sits there forever.

    Is there a way to manually uninstall it (I was thinking to backup the config, do a FACTORY RESET, and reload the config (without package information))


Log in to reply