By Jerimee on

How to set up Drupal cron jobs on a Bluehost hosting package:

login to your bluehost cpanel

go to the "advanced" tab

click "cron jobs"

choose the "standard" experience level

in the field "command to run" type the following

php -q /home/yoursite/public_html/cron.php

Where "yoursite" is the eight character default user name for your hosting package. Bluehost uses an eight character user name for each new package. This name is based off the domain name with extra characters if the domain name is less eight. If the domain name is more than eight, the user name is the first six to eight characters, with any additional characters being numbers. Contact BlueHost support (888.401.4678) if you do not know your eight character default user name.

If your drupal installation is hosted in its own directory, you will need to add that directory after "public_html" Like this:

php -q /home/yoursite/public_html/yourwebfolder/cron.php

Now all you have to do is select how often you would like the cron triggered. Select the months, days, hours, and minutes you would like the process to run.

Now click "Save Crontab."

Now you're done, and can got to your website to confirm that the cron jobs are in fact running. I confirm this by checking administer >>> logs >>> status report >>> Cron maintenance tasks

⋅ Categories: Drupal 5.x

Comments

bwv’s picture

bwv commented

Have you looked at the poormanscron module as an alternative to this arrangement?
----------------------------------------------------------------------
http://www.bwv810.com/

I am a writer and researcher. In my spare time I build websites with Drupal.
Je peux communiquer en français. / Я могу общаться на русском языке.

stoob’s picture

stoob commented

If you can run a 'real cron' on your server, why would you want to use poormanscron as an alternative? It is a performance drag and inefficient.

ryness’s picture

ryness commented

When I try this on my Buehost account I get:

Failed loading /usr/local/Zend/lib/ZendExtensionManager.so: /usr/local/Zend/lib/ZendExtensionManager.so: cannot open shared object file: No such file or directory

ed5876’s picture

ed5876 commented

Thanks...This worked perfectly for me.

ed

llazarte@drupal.org’s picture

llazarte@drupal.org commented

Thanks for your tip.

I have SSH access to Bluehost, but crontab is not available on the command shell, so your tip was quite useful.

I don't know how this Fantastico automatic installations are made, but I installed Moodle in Bluehost and a cron job was automatically created. Wouldn't it be nice if the same happened with Drupal?

Cheers,
Leonardo

bwv’s picture

bwv commented

You're welcome. Incidentally, fantastico and drupal are not a good mix, in my experience. Better to do a manual drupal installation, which will leave you with a site that is not prone to errors in the future.

----------------------------------------------------------------------
http://www.bwv810.com/

I am a writer and researcher. In my spare time I build websites with Drupal.
Je peux communiquer en français. / Я могу общаться на русском языке.

rrgandy’s picture

rrgandy commented

The above ran but with errors.

I was able to get the following to run without errors.

-- where domain.com is your domain name, and /cron.php is the directory where cron.php exists -- in my example, the root directory. Specify the appropriate path if cron.php is not in the root directory.

Richard R. Gandy

devildog’s picture

devildog commented

I had the same results with BlueHost and using the aforementioned cron command worked without errors or warnings.

curl http://www.domain.com/cron.php

Thanks Richard!

fiockthis’s picture

fiockthis commented

Thank you very much Richard, that is just what I needed.

curl http://www.domain.com/cron.php

works perfect.

gabrielu’s picture

gabrielu commented

Thanks. But I'm wondering why my bootstrap is generating output before session_start() - that was the previews error.

Sincerely,
Gabriel Ungureanu
https://ag-prime.com/

cpall’s picture

cpall commented

Check your home directory on your cpanel home!!

That's all, not everyone is

/home/USERNAME/....
there is

/home1/USERNAME/...

/home2/USERNAME/...

sammyframson’s picture

sammyframson commented

I had a home directory of home1 and would have missed that...

jaypan’s picture

jaypan
Location Victoria, BC
commented

You can find out your directory by typing 'pwd' when you are in the folder.

Contact me to contract me for D7 -> D10/11 migrations.

galeksic’s picture

galeksic commented

Maybe you should chdir to Drupal:

cd /home/yoursite/public_html/yourwebfolder/;php -q /home/yoursite/public_html/yourwebfolder/cron.php

josh33’s picture

josh33 commented

Thanks! I can only say I wish I had searched for a solution sooner!

MGParisi’s picture

MGParisi commented

Notifications and some modules will be unable to get the domain name needed for their applications to run. Therefor running the cron job as a script rather then as a web page will cause emails to have no domain name. Thus update notifications will have paths like this http:///node/123 and not http://www.example.com/node/123

There must be other reasons as to why the team at drupal runs this service the way it does. Very few things in Drupal are done without a great deal of attention to details.

I will look into the messaging application to see if I can fix this. There is a way to set the domain name in the system.ini file, however this does not fix the issue with notifications.

brianbrown’s picture

brianbrown commented

It you use the Simple Scripts service to install Drupal on a BlueHost server, it sets up a cronjob like this:

/ramdisk/bin/php5 -f /cron.php >> /dev/null 2>&1

(Note that the entries after the '>>' cause output to be suppressed (like an email)

However, BlueHost Support told me to use:

/ramdisk/bin/bash -q /homeX/yourusername1/public_html/cron.php

And another tech there said to use:

/ramdisk/bin/php5 -q /homeX/yourusername1/public_html/cron.php

But the ONLY thing I have ever been able to get to work is:

/usr/bin/wget -O - -q http://example.com/cron.php

This troubles me, since this creates a bandwidth issue as the server is going out to the public Internet (once a minute in my case), as well as cluttering up logs. I guess someone needs to tell BlueHost/Simple Scripts that their install script is broken.

Also for your information, Bluehost (and their subsidiaries) all identify your home directory (the SSH root) as 'homeX' where 'X' is some number.The Public webserver root is 'public_html' HOWEVER you can also use 'www' to reference the 'public_html' directory and/or simply 'home' to get to your 'homeX' directory, as on a normal *mix installation.
Regardsm
Brian Brown, Ph.D.

jkdaza’s picture

jkdaza commented

wget worked for me on Bluehost:

/usr/bin/wget -O - -q http://example.com/cron.php

Lakeside’s picture

Lakeside commented

BlueHost cron job does recognize the cron job. Problem is that there is a problem with the session_start function in bootstrap.inc file.

This cron job (command line was arrived in part by this thread--appreciate the help):

/usr/bin/php -q /home/user/public_html/exampledomain/cron.php

Results in this warning:

Warning: session_start() [function.session-start]: Cannot send session cookie - headers already sent in /home/user/public_html/exampledomain/includes/bootstrap.inc on line 1174

Warning: session_start() [function.session-start]: Cannot send session cache limiter - headers already sent (output started at /home/user/public_html/exampledomain/includes/bootstrap.inc:1174) in /home/user/public_html/exampledomain/includes/bootstrap.inc on line 1174

What is line 1174?

Line 1174 is 'session_start();' and is the last thing called in the DRUPAL_BOOTSTRAP_SESSION in the bootstrap.inc file.

Could it be FastCGI?

FastCGI does cache the PHP, so it was turned off--results the same. What I don't know is if turning off FastCGI in the control panel turns it off immediately or if it takes some time for the system to reset in which case this is irrelevant.

What BlueHost suggest

Although the problem persist after FastCGI was turned off BlueHost suggest that...

The Fast CGI could be a problem as it may be caching your session. if your session is cached, then you can't re-issue the command to start a new session.

You will need to remove the second session = start from your code so that it's only defined once in the cron. You may have to back trace your scripts a bit to find the first instance.

Which session command...and where is it?

Assuming BlueHost is correct and the second session needs to be removed which session call needs to be eliminated and which line is it?

Any help is appreciated.

////////////////////////////////////////////////////////////////////////////////////

Problem Solved

Changed:

/usr/bin/php -q /home/user/public_html/exampledomain/cron.php

To:

/usr/bin/php /home/user/public_html/exampledomain/cron.php

For whatever reason by omitting the deprecated '-q' the command line has been working.

Kasha Linka’s picture

Kasha Linka commented

This "fix" worked perfectly for me. When I created my cron job in cpanel (thanks to the clear directions from Jerimee at http://drupal.org/comment/reply/218139/), it was automatically converted from my initial entry:

php -q /home/yoursite/public_html/yourwebfolder/cron.php

to

/ramdisk/bin/php5 -q /home/yoursite/public_html/yourwebfolder/cron.php

This gave me the bootstrap.inc "session_start" warning. So based on your recommendation, I removed the deprecated -q command and all is functioning as expected.

Thanks very much!

dpatte’s picture

dpatte commented

i recently switch from cgi to fastcgi and was getting the same errors
I removed the -q and it now seems to work without errors

kimadamson1’s picture

kimadamson1 commented

This solution worked for me as well: /usr/bin/php /home/user/public_html/exampledomain/cron.php

Thank you!

tsorelle’s picture

tsorelle commented

After much experiment here is what works for me:

First of all I have some scheduled scripts that are intended to produce output that I get via e-mail when they produce some information or error. For these I use:

/ramdisk/bin/php5 -q /home/myusernamehere/public_html/myscript.php

Some posts here suggested that the '-q' switch is 'deprecated' and should not be used. I don't know how that term would apply to a command line switch. In any case -q is supported in the particular php5 version here. You can get the command line switch list simply by scheduling "/ramdisk/bin/php5 -?" in cron and then reading the resulting ouput in the e-mail message.

If the -q switch is not used the command will always produce the output below, and send me an e-mail for every run:

X-Powered-By: PHP/5.2.9
Content-type: text/html

Using -q ensures that I don't get a message when the script does not produce ouput. For my own scripts this serves me well. Cron.php, however, always issues a warning message, regarding the session. That means it produces an e-mail message for every run. You could remove the email address and get no messages at all but I don't want to disable messaging for my other jobs. So here's what I settled on for Cron.php:

curl -s http://www.mydomannamehere.org/cron.php

The -s supresses output from curl, so I never get a message from these runs. I rely on the error report in the Drupal admin screens to monitor Cron.php. I only run Cron.php once an hour. More frequently would generate an unwanted level of site hits.

If you do not intend to rely on the e-mail messaging feature for any of your scripts, you should simply blank out the e-mail address on the BlueHost "Standard Cron Manager" screen. Then you can use any of the variations of php5, curl, wget or whatever you like.

tsorelle’s picture

tsorelle commented

The more I thought about my CURL approach, the less I liked it. It is a bit of a kludge and I don't really like generating all those http requests. So I thought about how to make the cli approach work. The problems I needed to resolve were:

  1. Need to make the drupal site root the current directory.
  2. Need to pick up setting from the local custom php.ini file
  3. Need to surpress the spurious session warning

I accomplished all the above by including Cron.php in another little script that I named drupaljobs.php:

<?php
// settings from may local php.ini file:
ini_set('include_path','.:/usr/lib/php:/usr/local/lib/php:/home/your_user_name_here/php');
ini_set('memory_limit','96M');

// change to root directory of drupal site
chdir('/home/your_user_name_here/public_html');

// turn off error reporting
error_reporting(0);

// run cron.php
include("cron.php");

I now call this script from cron with:

/ramdisk/bin/php5 -q /home/your_user_name_here/public_html/drupaljobs.php

As with the curl solution this produces no output and consequently no e-mail. The error_reporting call in the script surpresses PHP warnings and error messages and the -q switch supresses the header output. So monitoring must be done using the Drupal admin reports.

jaypan’s picture

jaypan
Location Victoria, BC
commented

I've always used this on bluehost. I don't know if it's the right way, but it works:

/home/bluehost_username/public_html/scripts/drupal.sh --root /home/bluehost_username/public_html/ http://domain.com/cron.php

Where 'bluehost_username' is your bluehost username and domain.com is your domain.

Contact me to contract me for D7 -> D10/11 migrations.

TmaX-2’s picture

TmaX-2 commented

After i logged into my website after a week the cron job refused to run.. it kept telling me it couldn't run cron.
When i checked log entry it gave me this error ' Attempting to re-run cron while it is already running.'

Tried a lot of things but no results..finally decided to try the cpanel option...

'php -q /home/yoursite/public_html/cron.php' did the job for me smooth...
selected from the cron job tab to run cron daily...

I didnt install poormans cron and i still havent figured why my cron stopped running in the first place but i hope this can make things work..
Thanks Jerimee
Regards

jasenmichael’s picture

jasenmichael commented

mine stopped working also

I use
php -q /home/user/public_html/site-folder/cron.php

I get this error from cron email

Warning: session_start() [function.session-start]: Cannot send session cookie - headers already sent in /home/user/public_html/site-folder/includes/bootstrap.inc on line 1037

Warning: session_start() [function.session-start]: Cannot send session cache limiter - headers already sent (output started at /home/user/public_html/site-folder/includes/bootstrap.inc:1037) in /home/user/public_html/site-folder/includes/bootstrap.inc on line 1037

Lakeside’s picture

Lakeside commented

Bluehost has been upgrading their equipment over the past few weeks, which might be the source for some of the cron jobs failing. So far my solution has worked (posted above).

lelandnielsen’s picture

lelandnielsen commented

After upgrading to 7, finding cron no longer running, and trying all of the options above, this is what I found worked for me:

curl http://www.examplesite.com/cron.php?cron_key=alongstringofnumbersandlett...

Check your status report.
Highlighted in yellow, it should read "Cron has not run. To run cron from the outside, go to ..."
That's the link you want to paste into your cpanel cron job.

adellefrank’s picture

adellefrank commented

lelandnielsen's curl solution worked for me on Bluehost: hurray!