Poormanscron hang

I have the same problem too. I looked in the apache error logs and it says something about the server running out of threads and then the next line says "File does not exist: C:/wamp/www/favicon.ico". It took about 4 days and 30 reinstalls to isolate the problem to poormanscron. I'm using WAMP 2.0 on a windows xp system with 1GB of RAM and a 1.6Ghz celeron processor for development. I also noticed that Apache begins to eat up my memory when I try to install. Sometimes as high as 800MB. Don't know why that is.

Yes, I have a similar problem with Drupal 6.10. When I installed the module, I got a PHP memory error. I increased the PHP memory and then it would simply hang and I couldn't do anything in the Admin area at all. This development server is Windows XP running XAMPPLite.

I also installed the 5.x version in Drupal 5.15 with no problems whatsoever on a Windows 2003 server running the usual WAMP stuff.

This may not be a poormanscron problem. Do you get the same behaviour when you visit http://example.com/admin/reports/status and then click on the "run cron manually" link?

I've had no problem with running cron manually. I've worked around the need to install poormanscron by implementing the "footer block" method as described in the comment on this page: http://drupal.org/cron

Also, I think modifying the memory limits on the settings.php and .htaccess files (as described here http://drupal.org/node/29268 ) helps with the memory issue. It seems that changing the php.ini memory settings is not enough.

The footer block approach in many ways is similar to poormanscron.

poormanscron doesn't really do an awful lot ... since Drupal 5.x (which introduced http://api.drupal.org/api/function/drupal_cron_run/5) much of the code in it is now superfluous (and has actually been removed in 6.x-1.x-dev).

Since you are running 6.x-1.0 have you tried using the option to log progress of cron runs? How far does it get? There must be some difference in how cron hooks are getting invoked by poormanscron compared with other approaches, and as a result something is going wild in a cron hook I suspect (i.e. rather than in poormanscron itself). You could also try 6.x-1.x-dev, which uses drupal_cron_run() directly, and hence is even more similar to the footer block method.

well, whenever I install poormanscron I get "the white screen of death"

Q: but how to know how progress is going on?
A: before install it I set up the poormanscron_log_progress flag, even through code

or manually thought phpmyadmin, goint to table {variable} and inserting a new row with variable name to poormanscron_log_progress and value to i:1; (the serialized version of 1)
then I can track the progress, and every single attempt was frustrated due to search_cron

I disabled the search module (since I was using views exposed filters instead) and could install the poormanscron module and let it run cron several times without problems

Of course, a big deal is, if I'm installing poormanscron it's probably due to a custom installation profile which would like to be self-contained, meaning that there will be no external cron tab config, neither a previous manual execution of cron,
thus search_cron would always hang up (timeout) even in a fresh (custom) install which doesn't have any nodes created yet!

Until now, the solution is: do not enable search module, use views exposed filters instead
Nevertheless, this should be fixed, and probably it's not a problem of poormanscron, but update_index hook at search_cron or some other module's cron hook.

It might be very helpful that all of you track down where is the halting happening, so this issue can be figured out.

When cron hangs during search indexing it's usually because there is a node that contains PHP code which interferes with the indexing process. The other possibility is that you need to set it to index fewer nodes per cron run (e.g. try just 1 for testing purposes and see if it 1. can successfully run cron without hanging, and 2. whether the count on the search settings page of the number of nodes left to index gets reduced each cron run by 1).

Note you can also run cron (for testing) by going to the status report page and using the "run cron" link that is there (but bear in mind that this approach doesn't play very well with CCK content permissions if you are using them).

@gpk
NOT even a single node has been created
I was talking about a fresh empty (though custom) install
the "custom" part of the install is about creating custom content types, not creating even a single node

In my case running cron manually fails too, so it's better doing it through poormanscron with poormanscron_log_progress enabled, so I can figure out which module's cron hook it's halting it.

looking around for some cron and search_cron issues I found this one #303493: Cron not running correctly..
which make me think about a cck related issue (because in my case there are no nodes created yet), since the custom types I'm early installing have many cck fields (of several types, ugh.. that will be hard to track down...)

Do you get any errors in your server logs?
Does poormanscron indicate that some cron hooks are successfully run? If so, which?
If there are no nodes I wonder why search cron http://api.drupal.org/api/function/search_cron/6 is getting stuck..! The only module in core that implements hook_update_index() is node.module (http://api.drupal.org/api/function/node_update_index/6), though other modules have their say by implementing the 'update index' $op in hook_nodeapi() http://api.drupal.org/api/search/6/nodeapi. CCK will doubtless have its say there too.

You might want to do some hacking on a dev instance of your site, putting calls to http://api.drupal.org/api/function/watchdog/6 at suitable places, e.g. search_cron(), to track what is going on. Or fire up a debugger.

Having said all that, I can't quite see where node_update_index() is going to cause problems if there are no nodes ... in this case, it will I think do nothing. Maybe the problem is another module that implements that hook.

Good luck...

thanks a lot gpk!

well... I really wasn't fighting to get search module working, since I really wasn't using it at all in that custom install
I just posted here possible causes to help others to figure out their problems

yes I did stepped through with a debugger and indeed there was another module implementing hook update_index blocking search_cron (right now I don't remember which one, probably a cck related)
that was how I figure it out, enabling log for poormanscron which told me the progress made, then I looked up for the next module (with the same module sort in a query) and found it was search module, just that I didn't need it at all, I just debugged it for curiosity and found some update_index hook getting stuck, didn't go farther than that...

after having disabled the search module I kept adding modules to the custom install profile I was developing, so... more cron problems aroused

white screen, with NO a single PHP error in logs, with NO watchdog error either... how is that?

some fool module might be calling exit function
or maybe some fool human is trying to mix incompatible modules like elysia_cron which doesn't supports poormanscron neither "run cron manually"

BTW: what do the original posters of this issue have to say about it? did they find their problems?
for me its everything going on wheels, it doesn't seems to be any problem with poormanscron

I knew something was wrong when "cron run completed" messages were only showing up irregularly in the logs. Cron was being triggered (by poormanscron) but it wasn't completing. After finding this thread, I disabled the search module and all is well. Everything is going on wheels! ;-) I didn't investigate any further, but it doesn't seem like this is a poormanscron issue.

http://drupal.org/node/303493
http://drupal.org/node/501682
http://drupal.org/node/382682

So, sounds like this has been boiled down to a problem with PHP code in nodes and using search.module. Closing issue as a duplicate of the many core Drupal issues people have filed about this same problem.

It ended up that the problem I was having was not due to poormanscron or search.module, but a corrupted database (I had manually added some nodes with phpmyadmin-- not a good idea).