Note that the Linksys supplied version of crond (the one you get if you don't install the cron ipkg) is not a full featured cron. It appears to come from Lineo or SnapGear but I can't locate source code other than a few fragments that are only in Google's cache. Features known not to work are specifying a non root user (it runs the command as root regardless) and mail notifications (it relies on /bin/mail which doesn't exist).

(:table border=0 width=100% bgcolor=#eeeeff:) (:cell:)

  10 20 * * * /opt/www/data/outlook.sh (works)
  10 20 * * * root /opt/www/data/outlook.sh (did not work ...)

(:tableend:)

The second one, real cron, is part of cron package (cron_4.1-7_armeb.ipk at time of writting) and it HAS TO be installed in order for some other packages to work.

This second cron is started at boot time (thanks to /opt/etc/init.d/S10cron) in addition to the first one. The real cron reads main /opt/etc/crontab and additional crontabs placed in /opt/etc/cron.d.

NOTE: In fact there are TWO crons running on NSLU2. The first one, crond, is the default one and comes with Linksys firmware. It reads ONLY the /etc/crontab file. The second one, real cron, is part of cron package (cron_4.1-7_armeb.ipk at time of writting) and it HAS TO be installed in order for some other packages to work. This second cron is started at boot time (thanks to /opt/etc/init.d/S10cron) in addition to the first one. The real cron reads main /opt/etc/crontab and additional crontabs placed in /opt/etc/cron.d. One of ipkg packages that rely on real cron is ntpclient.

TIP: For OpenSlug 3.1 the sh jobs in within crontab did only work, when I did not enter the user name "root" in the command lines:

TIP: the sh jobs in within crontab did only work, when I did not enter the user name "root" in the command lines:

10 20 * * * /opt/www/data/outlook.sh (works) 10 20 * * * root /opt/www/data/outlook.sh (did not work ...)

WARNING: Prior to editing any environment variables, make a note of any important environment settings before changing them! Most environment variables will be reset once a user logs off and logs on, through entries in /etc/profile and so on. If you are unsure as to whether some settings will be restored, write them down at the very least.

TIP: if you see a line like:
May 17 9:00:00 (none) cron.info /USR/SBIN/CRON[2044]: (root) CMD (root^I/usr/local/bin/backup)
then try removing the username from your crontab, even though cron tells you to put it there.

TIP: rsync in a cron job didn't work for me if redirected to /dev/null. By removing the redirection, it worked fine.

Note that the LinkSys? supplied version of crond (the one you get if you don't install the cron ipkg) is not a full featured cron. It appears to come from Lineo or SnapGear? but I can't locate source code other than a few fragments that are only in Googles cache. Features known not to work are specifying a non root user (it runs the command as root regardless) and mail notifications (it relies on /bin/mail which doesn't exist).

TIP: rsync in a cron job didn't work for me if redirected to /dev/null. By removing the redirection, it worked fine.

If you are seeing an entry in /var/log/messages, but not the results of the command, ensure that the environment variables set at the top of the crontab file match those in your system environment. An example crontab is shown below. Note the entries for SHELL, PATH, and HOME.

0 0-23/8 * * * root /usr/sbin/CheckDiskFull &>/dev/null
0 0 * * * root /usr/sbin/WatchDog &>/dev/null \\

The cron daemon crond provides a means for users to schedule the execution of various commands. crond determines what commands to execute, and when to execute them through the contents of crontab. This file can be edited in any text editor and is usually found at /etc/crontab. For help on scheduling commands through crontab, please read http://en.wikipedia.org/wiki/Cron.

Having written a line in crontab for a scheduled task, a common problem involves the user not seeing the execution of their command, even though the command executes perfectly when typed at the command line.

First of all, ensure that crond has actually attempted to run the command at the correct time. Check /var/log/messages to see if crond has performed the command. If it has not done so, you may have set the command to run at the wrong date or time.

If you are seeing an entry in /var/log/messages, but not the results of the command, ensure that the environment variables set at the top of the crontab file match those in your system environment. An example crontab is shown below. Note the entries for SHELL, PATH, and HOME.

@@SHELL=/bin/sh \\

1 * * * * root /usr/sbin/hwclock -s &>/dev/null@@

You can check your environment variables by typing env. Remove or add environment variables as necessary until the environment settings match those in crontab. Since I was logged in via ssh, I did not remove any variables associated with sshd itself, such as SSH_CLIENT.

TIP: export VAR=value allows you to set or change environment variables. To remove a variable, simply set it to an empty string. I.e., export VAR="".

WARNING: Prior to editing any environment variables, make a note of any important environment settings before changing them! Most environment variables will be reset once a user logs off and logs on, through entries in /etc/profile and so on. If you are unsure as to whether some settings will be restored, write them down at the very least.

Once your environment variables match those of crontab, run your command from the shell and observe any error messages. The most common cause of problems is a missing path. Add variables to your environment one by one until the command executes from the command line. Now you will know what variables to set in crontab.

The cron daemon crond provides a means for users to schedule the execution of various commands. crond determines what commands to execute, and when to execute them through the contents of crontab. crontab can be edited in any text editor and is usually found at /etc/crontab. For help on scheduling commands through crontab, please read http://en.wikipedia.org/wiki/Cron.

Having written a line in crontab for a scheduled task, a common problem involves the user not seeing the execution of their command, even though the command executes perfectly when typed at the command line.

First of all, ensure that crond has actually attempted to run the command at the correct time. Check /var/log/messages to see if crond has performed the command. If it has not done so, you may have set the command to run at the wrong date or time.

If you are seeing an entry in /var/log/messages, but not the results of the command, ensure that the environment variables set at the top of the crontab file match those in your system environment. An example crontab is shown below. Note the entries for SHELL, PATH, and HOME.

(:table border=0 width=100% bgcolor=#eeeeff:) (:cell:) SHELL=/bin/sh
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=""
HOME=/
# ---------- ---------- Default is Empty ---------- ---------- #
0 0-23/8 * * * root /usr/sbin/CheckDiskFull &>/dev/null
0 0 * * * root /usr/sbin/WatchDog? &>/dev/null
1 * * * * root /usr/sbin/hwclock -s &>/dev/null (:tableend:)

You can check your environment variables by typing env. Remove or add environment variables as necessary until the environment settings match those in crontab. Since I was logged in via ssh, I did not remove any variables associated with sshd itself, such as SSH_CLIENT.

TIP: export VAR=value allows you to set or change environment variables. To remove a variable, simply set it to an empty string. I.e., export VAR="".

WARNING: Prior to editing any environment variables, make a note of any important environment settings before changing them! Most environment variables will be reset once a user logs off and logs on, through entries in /etc/profile and so on. If you are unsure as to whether some settings will be restored, write them down at the very least.

Once your environment variables match those of crontab, run your command from the shell and observe any error messages. The most common cause of problems is a missing path. Add variables to your environment one by one until the command executes from the command line. Now you will know what variables to set in crontab.

Airw0lf is going to write this.