Last updated March 7, 2013. Created by hansfn on May 24, 2006.
Edited by 2020media, jhodgdon, olafveerman, LeeHunter. Log in to edit this page.

Some of you might have trouble getting lynx or wget to work. This may be the case if "localhost" is not permitted.
Then wget, lynx or curl won't work on the local machine. If you are not willing to depend on others to perform cronjobs and you dislike poormans cron, try this script.

touch ~/scripts/cron-php.sh
chmod 700 ~/scripts/cron-php.sh
vi ~/scripts/cron-php.sh

#!/bin/bash
#
# Simple cron script for those who cannot
# use wget, lynx or curl because the host
# closed the localhost loop.
#
# Usage:
# - put this file in the ~/scripts dir
# - add a cronjob pointing to this script
#
# Copyright OCS - 2006
# Copyright hansfn@drupal.org - 2008
# This script is provided under the GPL.
#
# v 0.1 original release
# V 0.2 added PHP parser options and verbosity
#    setting to keep it quiet so real errors can
#    be reported by cron.
#############################
# CONFIGURATION OPTIONS
#############################
# Complete local path
#
# Set the complete local path
# to where the cron.php file
# is (ie the root path)
# Default is /var/www/html/
root_path=/var/www/html/
# Complete php path
#
# Set the complete path
# to the php parser if
# different from standard
parse=/usr/bin/php
# PHP parser options
#
# Defaulting to not report notices.
parse_options="-d error_reporting=2037"
# Verbosity
#
# Default to only report errors.
verbose=false
##############################
# END OF CONFIGURATION OPTIONS
##############################
cd $root_path
if [ -e "cron.php" ]
then
    $parse $parse_options cron.php
    if [ "$?" -ne "0" ]
    then
         echo "cron.php not parsed."
    else
         if $verbose
         then
             echo "cron.php has succesfully been parsed."
         fi
    fi
else
    echo "cron.php not found."
    exit
fi
exit

and then the crontab itself:
crontab -e
* * * * * ~/scripts/cron-php.sh

where ~ is the directory where your drupal install is (the script defaults to /var/www/html/ but your professional hosting company will probably use /home/your.domain.tld/www

Looking for support? Visit the Drupal.org forums, or join #drupal-support in IRC.

Comments

We currently run our apache environment with 30 second timeouts to prevent huge traffic backlogs when our server gets overloaded. The Apache will stop the php script execution after 30 seconds.

Our crons frequently need more than 30 seconds to complete. This was causing the scripts to end abnormally and never remove the cron_semaphore variable drupal uses to prevent duplicate cron jobs from running concurrently. The only solution was to remove the semaphore manually and rerun the cron. But again, the cron would take too long and we would be back in the same situation again.

We can't remove the apache timeouts as they help us to recover quickly from huge traffic events which we frequently incur.

This turned out to be the perfect solution. By running the cron from the command line and not in via http we are not subject to the Apache timeouts.

Thanks for the great post.

We are using this script to run cron on a Linux dedicated server, and we get the following warning:

"PHP Notice: Undefined index: HTTP_HOST in [...]/httpdocs/includes/bootstrap.inc on line 204
PHP Notice: Undefined index: HTTP_HOST in [...]/httpdocs/includes/bootstrap.inc on line 261
cron.php has succesfully been parsed."

I have changed unrelevant path to [...].
From the cron job page on Drupal.org I understand that PHP notices happen because Drupal's cron.php does not like being run via a shell script.
But, the script gets to the final ok message anyway. Are these notices unrelevant? In this case, I could switch them off by redirecting output to dev/null.
But again, in the site's Drupal admin section, log report page, I am told that cron has not run.
I do not understand if the script is actually working or not!

Thanks for any suggestions!

Try this patch (use the first one, in the initial post): http://drupal.org/node/346285
This issue was introduced recently with the SA-2008-067 security patch. Previously, HTTP_HOST wasn't checked by Drupal.