Drupal Cron.php Failure After Upgrade

I had a problem with cron not running after upgrading from 4.7 to 6.2 (with a hop thru 5.x). The log kept showing the error "Cron run exceeded the time limit and was aborted.". I could kick off the cron.php script, but it would always come right back with the error.

I checked php.ini it allowed longer running scripts, so the error was spurious.

Since the error message only meant that cron.php was crashing (not taking to long), I thought it might be a problem with one of the modules failing. I only had a few modules running, other than core and the standard ones, so I kept disabling them until cron.php would run. I found that if I disabled search, cron would run.

I had cut the number of items to index down to 10 in the search settings, so it seemed there was some problem with content on my site as it went thru search. I had too many entries to go thru things one at a time, so I decided to reset the search tables and see if search stopped on a certain node and I could then tell what was wrong.

I'd recommend you do a backup of your database before trying anything like this. Also, using something like phpMyAdmin might save you a little trouble.

I dropped down to the MySQL command line and reset all of search tables by hand:

mysql> DELETE FROM search_dataset;
mysql> DELETE FROM search_index;
mysql> DELETE FROM search_node_links;

I hit the re-index site button on the "Search settings" drupal page and waited a few minutes. It kept updating until it quit at 71% indexed, without getting an error in any of the logs.

Now I could go back to MySQL and find out what node it last successfully indexed:

mysql> SELECT * FROM search_index;

The last nid shown was the last one indexed. In my case, that was nid 87, so my problem looked like it was with nid 88. When I tried to bring that node up directly:

http://www.mojocode/node/88

The browser stopped responding.

However, when I navigated thru the content, I could get to it.

It turns out it was an old "robots.txt" workaround that would serve up a robots.txt page that I had gotten off the drupal forums or someone else's how to on a website. I vaguely remember creating it a few years ago, when I was back on 4.7. It was a bit of php code that threw a Header of 'Content-type: text/plain' and then some Disallow: directives. The final killer was probably the lines that say:

<?php
die();
?>

It appears that when the search module is evaluating the text on a node, it evaluates the php script that is contained therein. Thus, when it hit this fake robots.txt generator, it kills the indexing process.

I disabled the PHP by changing the input format to "Full HTML" instead of "PHP Code" and unpublished the page.

After saving the changes, I was able to re-index the site in a few minutes and now cron.php is running flawlessly again. I have the added benefit of actually using the robots.txt file that comes with the standard drupal install. Technically, this may not be an update issue, but it only came to light after I upgraded. Prior to upgrading, it appears that search was fully functional (maybe not, though).

sj