NSLU2-Linux
view · edit · print · history

HowTo.DebugCrontabProblems History

Hide minor edits - Show changes to markup

October 24, 2007, at 12:40 PM by fcarolo -- fixed false wikilinks
Changed line 56 from:

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

to:

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

October 24, 2007, at 07:45 AM by Darek -- minor formating changes
Changed lines 49-53 from:

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

to:

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

October 24, 2007, at 04:40 AM by Darek --
Added lines 3-4:

Changed lines 13-14 from:
to:

October 24, 2007, at 04:39 AM by Darek --
Added line 4:
Changed lines 6-8 from:

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.

to:

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.

October 24, 2007, at 04:38 AM by Darek -- Existence of two crons: crond and cron was explained.
Added lines 3-8:

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.

April 29, 2007, at 09:45 AM by Rigas -- Syntax correction
Changed lines 35-36 from:

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

to:

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:

April 29, 2007, at 09:41 AM by Rigas -- Syntax correction
Added lines 35-41:

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

May 18, 2006, at 10:32 AM by nschum -- added another curiousity
Changed lines 25-26 from:

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.

to:

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.

Added lines 31-34:

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.

October 14, 2005, at 11:44 PM by Adam Baker -- Add some info on cron origin and limitations
Changed lines 29-31 from:

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

to:

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

August 28, 2005, at 05:41 PM by Ray Moritz --
Added lines 28-29:

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

August 14, 2005, at 12:35 AM by Airw0lf --
Changed lines 7-8 from:

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.

to:

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.

Changed lines 16-17 from:

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

to:

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

August 14, 2005, at 12:30 AM by Airw0lf --
Changed lines 1-8 from:

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.

to:

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.

Changed line 11 from:

SHELL=/bin/sh \\

to:

@@SHELL=/bin/sh \\

Changed line 18 from:

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

to:

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

Changed lines 21-27 from:

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.

to:

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.

August 13, 2005, at 12:49 PM by Airw0lf -- Tips on debugging problems with crontab
Changed lines 1-27 from:

Airw0lf is going to write this.

to:

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.

August 13, 2005, at 12:10 PM by rwhitby --
Added line 1:

Airw0lf is going to write this.

view · edit · print · history · Last edited by fcarolo.
Based on work by Darek, Rigas, nschum, Adam Baker, Ray Moritz, and Airw0lf.
Originally by rwhitby.
Page last modified on October 24, 2007, at 12:40 PM