I want to verify if a certain crontab works properly. I have added a job like this:

  */2 * * * * /path_to_my_php_script/info.php >/dev/null 2>&1

I know that i redirect to the null device, but i not sure if the above command is good.

*Edit 1: In my /var/log/syslog every two minutes i have the following error:

 (CRON) error (grandchild #2788 failed with exit status 2)

*Edit 2: No errors in logs with this new job:

 */2 * * * * /usr/bin/php /path_to_my_php_script/info.php >/dev/null 2>&1
  • unfortunately all above tried but does not work for me. as you say the trial /bin/sh -c "(export PATH=/bin; /tmp/trial.sh </dev/null)" shows below message, not sure what it is /bin/sh: PATH=/bin: is not an identifier – user284525 May 23 '14 at 11:03

The syntax for the crontab entry looks correct. Indeed, if you edit your crontab using "crontab -e" (as you should), you'll get an error if you specify a syntactically invalid crontab entry anyway.

  1. Firstly, does /path_to_my_php_script/info.php run correctly from the command-line?

  2. If so, does it also run correctly like this?:

    /bin/sh -c "(export PATH=/usr/bin:/bin; /path_to_my_php_script/info.php </dev/null)"
  3. If that works, does it work like this?

    /bin/sh -c "(export PATH=/usr/bin:/bin; /path_to_my_php_script/info.php </dev/null >/dev/null 2>&1)"

Step (3) is similar to how cron will run your program (as documented in "man 5 cron".

The most likely problem you're having is that the PATH cron is using to run your program is too restrictive. Therefore, you may wish to add something like the following to the top of your crontab entry (you'll need to add in whatever directories your script will need):


Also note that cron will by default use /bin/sh, not bash. If you need bash, also add this to the start of your crontab file:


Note that both those changes will affect all the crontab entries. If you just want to modify these values for your info.php program, you could do something like this:

*/2 * * * * /bin/bash -c ". ~/.bashrc; /path_to_my_php_script/info.php"

It's also worth mentioning that on a system configured for "mail" (in other words a system which has an MTA configured [sendmail/postfix/etc]), all output from crontab programs is sent to you via email automatically. A default Ubuntu desktop system won't have local mail configured, but if you're working on a server you can just type "mail" in a terminal to see all those cron mails. This also applies to the "at" command.

  • 2
    I get permission denied for 2nd step. What should i do? – akikara Jan 15 '15 at 23:07
  • 1
    @akikara chmod +x ./cron.sh - obviously replace ./cron.sh with whatever the location of your file is that you're trying to run – Tisch Jan 14 '16 at 15:45

Although very rare, sometimes cron stops working properly even though the service is running. Here is how to verify that crond is running and stop/start the service.

On Linux:

service crond status
service crond stop
service crond start

On Ubuntu and other Debian-based systems:

service cron status
service cron stop
service cron start
  • 2
    Seems to be /etc/init.d/cron status on my machine. – mpen Feb 20 '20 at 4:41
  • @mpen service is for systemd (which was adopted by many Linux distributions). Older releases and some distributions may still be using the old System V scripts in /etc/init.d. – mrm Mar 4 '20 at 2:09
  • This happened to me me into a docker machine. I would check this before more complex solutions. – ruizfrontend Jun 10 '20 at 8:05
  • Works also in WSL2 – marcin2x4 Jan 19 at 14:55

Do not redirect error output to /dev/null and grep /var/log/syslog for cron output.

grep cron /var/log/syslog

You can immediately show errors when saving a file after editing /etc/crontab or files inside /etc/cron.d/ with:

tail -f /var/log/syslog | grep --line-buffered cron

If the edit is ok, you will only see the RELOAD notice, errors will occur like

Jul 9 09:39:01 vm cron[1129]: Error: bad day-of-month; while reading /etc/cron.d/new 

You can see your active cron with the terminal command:

crontab -l

Here are the parameters in order:

  1. min (0 - 59)

  2. hour (0 - 23)

  3. day of month (1 - 31)

  4. month (1 - 12)

  5. day of week (0 - 6) (Sunday=0)

  6. command

So, you are calling your script every first minute of each hour. You should test your output at a more often interval for testing purpose:

* * * * * <command> #Runs every minute

This will call it every minute!

  • 1
    */2 * * * * i have changed to every two minutes now – croppio.com Dec 6 '11 at 10:15

For the time part on each line, you can use this cron tester to test/verify your cron time definition.


Old question and many complicated answers. The easiest way is to add this line to your crontab

* * * * * /bin/bash -l -c 'date > ~/cron-test.txt'

It will simply every minute write the current date to the file ~/cron-test.txt

Then you just run cat ~/cron-test.txt and check if the shown date is the current date. If it is crontab is working correctly.


I believe you can also use run-parts to run cron jobs out of band. It is actually what cron uses itself to run the periodic cron jobs, so by supplying the appropriate arguments you can run them at any time.

If you just want to run one file instead of all the cron jobs defined in eg /etc/cron.daily you will have to supply the regex argument along with a valid regex. run-parts --list --regex '^p.*d$' /etc

Keep in mind that cron jobs are typically named without an extension and marked as executable, so make sure your scripts are similar, though using a regex may allow you to trigger a script with an extension.


ah !!

got the answer myself, I checked and did not find crond inside the default installation directory i.e /etc/init.d/

will now try and reply.

note -- I did check the cron.allow, cron.deny too. All is fine so far.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.