By gawan on

Hello friends,
I tried http://mysite/cron.php and "re-index" button in http://mysite/admin/settings/search
but I have still "0% of the site has been indexed. There are 1127 items left to index."
And of course I have no result when I try to search.

I tried to change "Items to index per cron run" 10,20,50,100
and "Minimum word length to index:" 3,4,5,6
with no success....
I am desperate ....

Have you any idea where could be a problem?
(I use Drupal 4.7.3)

thanks.

⋅ Categories: Drupal 4.7.x

Comments

JamesSharpe’s picture

JamesSharpe commented

Do you have the CREATE TEMPORARY TABLE database permission set on the database user that accesses the drupal database? I had this problem as my host doesn't provide the TEMPORARY TABLE permission set. Try doing a search and if it gives you two warnings, one related to a missing table then its due to missing permissions.

gawan’s picture

gawan commented

I have it on my localhost (on my notebook with ubuntu) and I use user root without password with all privileges
($db_url = 'mysql://root:@localhost/test';) ....

Anonymous’s picture

Anonymous (not verified) commented

I'm having this same issue and if you resolved your issue I would like to know how.

Tia,
Earnie

deo_manish_drupal’s picture

deo_manish_drupal commented

Even i'm facing the same problem.
The Search engine is not working.
I have run the cron.php even though
its not working.

Please help me if someone has solved this problem.

inforeto’s picture

inforeto commented

Tracking this post.

Same issue of index at 0%.
Cron runs and leaves the watchdog entry, and scheduler works.
Manually running cron.php results on a blank page.

JohnG-1’s picture

JohnG-1 commented

same problem with shiney new Drupal 5.0 install.
no search indexing either manually or on cron run.

PS I can't find a drupal.org/project/... for this optional core module to log a bug report to (would seem the obvious way ...)

manoz_79’s picture

manoz_79 commented

Were you able to solve the problem? I am facing the same problem, with new Drupal 5.1 install, any suggestions?

inforeto’s picture

inforeto commented

Some search results.

http://drupal.org/node/66527
http://drupal.org/node/67015
http://drupal.org/node/42277

All i can notice is that node_cron_last is not on my variable table.
I assume cron is crashing, however the watchdog entry "cron has completed" is there.

funana’s picture

funana commented

exactly the same here...

jjjdokes’s picture

jjjdokes commented

New local installation of 6.3 has the same problem (shows "0% of the site has been indexed," after manually running cron and indexing).

DjC4’s picture

DjC4 commented

Same problem...subscribing.

funana’s picture

funana commented

Gush... I can't remember how we solved it, but it works...

What I can say is, that we're only indexing 10 Items per cron run (once p. hour) and that we maybe had a problem with another module during the cron, because search index build wasnt executed although watchdog said it was okay.

Maybe you should analyze your cron run with this: http://drupal.org/node/123269

brewermfnyc’s picture

brewermfnyc commented

My problem was actually caused by Übercart. So this was the fix I found after checking my php log files:

http://www.ubercart.org/issue/10504/call_undefined_function_uc_attribute...

Just added an underscore to line 325 so I could stick with Übercart 6.x-2.0-rc2.

paintingguy’s picture

paintingguy commented

Hi,

I'm using the latest version of Drupal 6 ( love it).

I've managed to migrated a vBulletin 4 forum over to drupal.

Cron works without showing any errors but doesn't seem to update anything.

It stays at 0% indexed with 35,720 not indexed.

I'm wondering if its because I have so much to index, this is causing it to not work? I have 120m memory for php. Permissions are all good.

Any help here would be great. I'm so close to being drupalized!

Nameless-3’s picture

Nameless-3 commented

Is cron not showing errors? I am using Drupal 6 as well, but cron isn't working at all. I don't know why. Also, I don't understand the "indexed 0%" thing, and what it means by that. How do you run cron and make it running?

Thanks, Nameless

inforeto’s picture

inforeto commented

If cron is not showing errors it will take some troubleshooting to find out which module is interfering with it.
Since cron executes code from several modules it can die silently for a wide number of reasons but can usually be tracked down to a recently changed module or memory issues.

It may run the hooks from the first few modules and stop at some point leaving out modules like search depending on the module's weight.
You can also take a look at the cron related variables in the variables table, if the date is wrong resetting it may work.

Another common issue is errors in php code in nodes which are easy to make and can stop cron from further processing.
These usually get logged but if not you'd have to check any custom php in nodes, snippets, patches, theme templates and content templates, custom views, etc.

ccshannon’s picture

ccshannon commented

Same here: Drupal 6.10. Stopped indexing at 42%, re-indexed and cron has run at least three times and says 0%.

The logs say cron runs and completes. This is a serious problem. I have lots of people angry with me (and Drupal) because of this issue.

Does anyone have any idea of a way to find an actual fix?

My development site (same modules, templates, etc) indexes fine, but not production. I can't go turning modules off and on, on a production site.

I added some content types this week, and while adding them to search, found that the search had topped off at 44%, which must have happened weeks ago, and now I have no idea what could be causing it.

I have no PHP errors that I know of. I can't think of any new modules added in the last couple months that could have interfered. Ugh. This is awful.

inforeto’s picture

inforeto commented

No need of stopping a production site when possible.
One way is to make a backup and troubleshoot on a copy of the site.
The modules list may be big but the list of modules that use the cron hook is probably small.

To find nodes with broken php you may be able to look at the database to find which ones were the last nodes indexed before it stops?
Not sure on this one i dont know if there's any data on which nodes have been searched.
Else nodes may have to be checked one by one but the site admin may know which users have php permission to then trim down the list.

Any modifications to templates or function theming may be easy to identify and it's a good idea to keep a log of changes to custom code and patches.
On the other hand downgrading modules isn't a good idea and is best to identify a bug to have it reported.

Unfortunately nor search nor cron have data on which module is giving errors so it has to be done manually.
One idea could be adding a call to watchdog to the cron hook on search module so that it runs before indexing a node and thus pinpoint the broken ones.

Problems elsewhere may appear on the server logs, like with server or memory problems, file permissions, etc.
Mysql running out of ram should show up in the apache error_log.

If all fails, open a support issue with the list of modules with versions and any other site info that may help.

paintingguy’s picture

paintingguy commented

This may help you. I realized my permissions for cron needed to be set to anonymous . My sever couldn't complete the cron until I did this. Now, it works perfect. 12 million full now.
If anonymous isn't an issue or if anyone knows how to do it differently, please share?

inforeto’s picture

inforeto commented

Wouldn't hurt to still keep an eye for any broken code on pages or module issues, just in case.
Bypassing permissions on cron as a workaround is ok if there's no dynamic nodes that need special treatment for the indexing.

cledman’s picture

cledman commented

hi.. i have almost the same trouble: My site stays at 0% and when i try to rebuild, it redirects me to the EVENTS´module page.
I try to install the REINDEX module and it fails at the end and just says that reindex 68%.

I have installed the Elysia Cron and it shows me that search_cron is not running .

Any idea?

jweowu’s picture

jweowu commented

FWIW, right now, it looks like the search_config module is interfering with my ability to Re-index the site.

If you have that enabled, see whether disabling it helps.

Specifically, in search.admin.inc, the #validate setting is undone by the hook invocation.

  $form['#validate'] = array('search_admin_settings_validate');

  // Per module settings
  $form = array_merge($form, module_invoke_all('search', 'admin'));

edit: See #565232: little bug in validate function

ccshannon’s picture

ccshannon commented

Here was the problem for the site I mentioned above, which is temporarily fixed, but needs further work.

Found here http://www.darcynorman.net/2006/06/07/drupal-search-funkiness/ - specifically comment #4.

I implemented an 'Editions' type homepage for the site, so the editors can customize a homepage and schedule it to go live at a certain date/time.

So, I don't want these homepage edition nodes to be searchable. The editors make about 3-4 copies of the homepage a day.

I had search_config set to not index these nodes (as well as some other node types I don't want in the results).

The maximum number of index-able nodes per cron run is 500. If I have more then 500 of any one node type that is not supposed to be index-able (like the homepage edition node type) then the indexer will not finish indexing them, but the next time cron runs, it thinks it is indexing that type for the first time, so it starts over with them, and the indexer never gets to the valid node types.

By hacking into search.module and adding a max of 2000, the indexer was able to finish with the homepage type and move on. Of course, either I have to have a cron purge the old homepage editions to keep the number low, or else I have to do what the comment in the link says ... copy node.module to sites/*/modules/ and hack the node indexing function to specify which types can be indexed.

The issue is with search config, because, despite the settings form saying you can exclude the indexing of certain types ... they get indexed anyway.

I wish the ability to control search indexing and results was part of core search module. It seems like a pretty reasonable feature to include as standard.

turboy’s picture

turboy commented

Ok guys, I'm not sure I got your same problem, but I'm sure that before I had

"0% of the site has been indexed. There are 23 items left to index"

and now I have:

"100% of the site has been indexed. There are 0 items left to index."

What I do? First I investigate through google/forums but I find only other questions.

I got the answer here: http://drupal.org/handbook/modules/search/ and here http://drupal.org/node/23714

I try to resume it for you.

I think there is a linking problem inside the search module itself and when you click on the "cron maintenance task" link you are not pointed in the right place.
I did this simple think:

  • 1. I run the cron directly in this way, writing the full address http://www.yoursite.com/cron.php in the adress-bar of my web-browser and pressing Enter (to me it returned a blank page)
  • 2. lets go to the search settings http://www.yoursite.com/admin/settings/search and click re-index site button
  • 3. now you should have your "100% of the site has been indexed. There are 0 items left to index"

Please let me know if it works to you too.
JSR

beyers’s picture

beyers commented

Perfectly, thanks!

joris.verschueren’s picture

joris.verschueren commented

I struggled days on end with what I thought to be a conflict between the search module and cron.php, to find that there's a whole litterature on this site about "bad php" blocking the indexing process.
As far as I've understood, the indexing process is sent astray by faulty php-code on a node (cause) and you get a cron timeout message (symptom).
should this hypothetically be your case as well, I found this thread http://drupal.org/node/361171 to be the most helpful and understandable.

regards

husayn’s picture

husayn commented

If you goto http://www.example.com/cron.php and are getting a 500 - Internal Server Error. It might be due to time limit exceeded. Therefore, go into the cron.php file in your webroot and change @set_time_limit(240); (increase the 240 to some larger number) and re-run http://www.example.com/cron.php . This should solve your problems and index the website.

deepakrmklm’s picture

deepakrmklm commented

I have faced the same issue, when I re-indexed my Drupal site.

Interestingly, It was due to an unsupported content in the database (HTML field), which causes error in cron run.

  <td>&#1048678;</td>