I have a cron job which deletes nodes. When I look at the SuperCron table it shows that the hook is run every hour as it supposed to, but no nodes are ever deleted.

However, when I click the Invoke link manually for that module's cron hook, the nodes are deleted. So the code is fine but I have no idea why it doesn't fire when the hook is called automatically.

Could this be related to set_time_limit issues in core since 6.14?

Comments

haojiang’s picture

haojiang commented

maybe i come up with the same error as yours
in my page cronqueue.php:
[code]supercron_invoke_one('job_queue');[code]
this code run only once and then i got blankpage;
then i change supercron.module-----function supercron_invoke_one,add var_dump for testing
i found out that "module_invoke($module, 'cron');" did not run at all.

finally , i found out that in one of my private function , i use exit() instead of return.
when cron come up with exit , it runs no more.
hope it helps

MisterSpeed’s picture

MisterSpeed commented

The best way to diagnose this is to first try Invoke All. Did it work ? If so, there is almost no difference in code between Invoke All and Supercron.php (in the end, both call the same process, it's just that supercron.php needs to bootstrap Drupal and go through the firewall check, then itc alls the very same method). So this limits the possibilities:

1. Is the firewall enabled ? If so try to disable it. There is a bug in 1.3 that makes it so that if you call curl or wget to get supercron.php to work it does, but if you use the interpreter directly (/usr/bin/php or somesuch) then the IP address returned by the process is not 127.0.0.1 but just nothing. We fixed that in 1.4.

2. If the firewall is disabled and the nodes still are not deleting (I'm assuming a Linux or Windows set-up here), make sure that the user associated with the cron call has the proper access right to do any database or file accesses; usually Invoke All is called through whichever user your web server is running under, but cron often does with a user that has different privileges.

3. Make sure also that supercron.php is actually being called; the Last Called date and time will indicate that if you do not touch Invoke All. In 1.4 the date and time refreshes all by itself through AJAX calls.

If all of this has been tried and you still face problems, would you mind sharing with me your configuration (through http://drupal.org/project/issues/configdoc ) or the module that is causing problems ?

Cheers,

Louis-Eric

MisterSpeed’s picture

MisterSpeed commented
Status: Active » Postponed (maintainer needs more info)
MisterSpeed’s picture

MisterSpeed commented

Pls. try 1.4: http://ftp.drupal.org/files/projects/supercron-6.x-1.4-beta1.tar.gz We have added new diagnostic and compatibility code to help work out such issues.