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
    Commented May 23, 2014 at 11:03

9 Answers 9


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.

Using systemctl:

systemctl status cron
systemctl restart cron

Older methods:
On CentOS and other Red Hat-based systems:

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
    Commented Feb 20, 2020 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
    Commented Mar 4, 2020 at 2:09
  • This happened to me me into a docker machine. I would check this before more complex solutions. Commented Jun 10, 2020 at 8:05
  • Works also in WSL2
    – marcin2x4
    Commented Jan 19, 2021 at 14:55
  • 1
    systemctl status cron Commented Feb 9, 2022 at 13:17

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
    Commented Jan 15, 2015 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
    Commented Jan 14, 2016 at 15:45

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 Commented Dec 6, 2011 at 10:15

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.


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

  • 2
    also useful: crontab-generator.org
    – rubo77
    Commented Feb 4, 2017 at 15:11
  • broken link to cron tester
    – Seamus
    Commented Mar 23, 2022 at 21:39
  • @Seamus the link is broken now but not when I had answered, so please don't down vote Commented Apr 21, 2022 at 2:14
  • If there were anything of any value at all here - other than a link to the answer, I wouldn't downvote. But without that link, your answer definitely is in the category of This answer is not useful. I'm sorry, but if you want to edit your answer, I'll gladly take another look. I don't like to downvote - this is only my 2nd downvote here in almost 4 years.
    – Seamus
    Commented Apr 21, 2022 at 3:23

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.


First of all, you have to check the cronjob status :

systemctl status cron

after that, run this command in the shell :

crontab -e

and add this line to crontab:

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

this command writes the current date every minute in the cron-test file, you can watch the crontab output with the following:

cat /tmp/cron-test.txt

you should have an output like this after 4 minutes :

Mon Mar  6 11:55:01 UTC 2023
Mon Mar  6 11:56:01 UTC 2023
Mon Mar  6 11:57:01 UTC 2023
Mon Mar  6 11:58:01 UTC 2023

now, if you can see this output your crontab works well, else you can see your log and find your issue's reason

grep cron /var/log/syslog



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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .