crons / scheduled tasks are not running...

[jeremycs]

None of my vbulletin crons / scheduled tasks are working.

For testing purposes I have created a test cron that will run every minute and call a file test.php which will simply append output of the current date & time to a file.

If I manually run this cron via "run now", it works... the test file has new output. If I call the test.php file directly from my browser it has new output as well.

I have confirmed that $cronimage is in my footer properly.

I have loaded a page (executing $cronimage) with and without hooks disabled.

I have directly called cron.php?&rand=##### (using a random number each time) with and without hooks disabled.

But there is no output from the test.php (meaning no scheduled tasks being executed) when I do any of this.


This behavior started after a move to a new network.
(backed up & reinstalled php files and mysql database)

Old server was running mysql 4.1.x
The new server is running mysql 4.1.x

Old server was running php 4.x
New server is running php 5.x


Any suggestions here?

[jeremycs]

UPDATE:

We've traced this to being caused by us running PHP5 on the new server.

In PHP5, when "START MAIN SCRIPT" section of cron.php is ran, for some reason $vbulletin->options['crontab'] is null or 0....

While running PHP5, we got the crons to run again by inserting this line:

// #######################################################################
// ######################## START MAIN SCRIPT ############################
// #######################################################################

header('Location: ' . $vbulletin->options['cleargifurl']);

($hook = vBulletinHook::fetch_hook('cron_start')) ? eval($hook) : false;

$vbulletin->options['crontab']=1;  // THIS LINE WAS INSERTED TO MAKE IT WORK ON PHP5
if (!defined('NOSHUTDOWNFUNC') AND !$vbulletin->options['crontab'])
{
      vB_Shutdown::add('exec_cron');
} 

But since there are other annoying glitches as well, (like private messages no longer alerting people of new messages) we've just opted to drop back down to the PHP 4.x branch for now.


Dropping to PHP 4.x seems to have solved all of our move related problems.