Cron not working?

jimp

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

jlepthien

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?

jimp

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

jlepthien

Yep. Works from shell.

jimp

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.

jlepthien

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

gordslater

@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**

gordslater

@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.

jlepthien

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

woodmouze

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))