0

I am using multidomain site .
After adding a new domain record, I was asked as follows: Content access permission needs to be rebuilt on this page.

When I clicked on Rebuild Permissions button, the progress bar started the batch operation of rebuilding but in the midway it stopped and gave an error given below

Rebuilding Content Access Permissions

An error has occurred. Please continue to the error page An HTTP error 0 occurred. /index.php?q=batch&id=433&op=do

I then searched an found an issue similar to the above in the link given below

https://www.drupal.org/node/399572

I found many solutions from above like :

  1. Run rebuild permission via cron (did not try)
  2. change theme and move to older jquery version (did not try as its live site) I checked the settings for jquery update and had "minified" instead of "none", once set to the correct setting, it worked within seconds.

I was using jQuery update module with jQuery 1.4. This causes the batch to not update.

  1. (did not try) To fix it, you have to prevent newer jQuery from loading when the URI contains "batch".

    <?php
    function node_access_rebuild($batch_mode = FALSE) {
      db_query("DELETE FROM {node_access}");
      // Only recalculate if the site is using a node_access module.
      if (count(module_implements('node_grants'))) {
    //      if ($batch_mode) {
          if (FALSE) {
          $batch = array(
            'title' => t('Rebuilding content access permissions'),
            'operations' => array(
              array('_node_access_rebuild_batch_operation', array()),
            ),
            'finished' => '_node_access_rebuild_batch_finished'
          );
          batch_set($batch);
        }
    ?>
    

    Not sure why this is happening to me, but I've found that I can just force node_access_rebuild() to not use batch mode by changing line 2314 of node.module from:

  2. In node.module this piece of code, is setting time limit to 240 secs which might be still low than ur php.ini. You can try increasing set_time_limit arg to 1000 and then changing it back to 240 to keep code consistent.

     if (!ini_get('safe_mode')) {
            set_time_limit(240);
          }
          $result = db_query("SELECT nid FROM {node}");
          while ($node = db_fetch_object($result)) {
            $loaded_node = node_load($node->nid, NULL, TRUE);
            // To preserve database integrity, only aquire grants if the node
            // loads successfully.
            if (!empty($loaded_node)) {
              node_access_acquire_grants($loaded_node);
            }
          }
        }
      }
    

What I tried was increased the max_execution_time from 30 to 1000? But still it did not solve the problem Then finally I tried rebuilding permissions via drush

using drush command

drush php-eval 'node_access_rebuild();'

But that gave me the following error as shown below

PHP Fatal error:  Maximum execution time of 240 seconds exceeded in 
sites/all/modules/me                                                                                     mcache/memcache.inc on line 353

Does the above error means this is something to with memcache and will it be worth trying to disable the memcache and then perform rebuilding node access?

http://example.com/index.php?q=admin/content/node-settings/rebuild

  • 1
    "Does the above error means this is something to with memcache" - not really. It will show whatever function is being processed when timeout happens, so if some function took 239 seconds and memcache only took one second so far, it will still show error to happen in memcache. – Mołot Jan 16 '15 at 10:13
  • any possible way to debug and solve this – harshal Jan 16 '15 at 10:14
  • I'm afraid you won't like it: only thing that comes to my mind is xdebug. Or turning memcache off and rebuild, in case it actually happens to be it's fault. First would take quite a bit of time. Later would either be fast, or a complete waste of time. – Mołot Jan 16 '15 at 10:18
  • what is xdebug and is it ok to implement on live site? any pointers would be beneficial – harshal Jan 16 '15 at 10:32
  • 1
    Xdebug - Debugger and Profiler Tool for PHP should not be implemented on live site. It will kill performance. And if you have no experience in setting it up, you may break things in the process. – Mołot Jan 16 '15 at 10:39
0

Set max_execution_time = 0 in php.ini to allow unlimited execution times, and disable the set_time_limit() PHP function (also via php.ini) to prevent Drupal from self-limiting its execution time back to 240 s. Otherwise, you would have to find all the places where Drupal calls set_time_limit() and increase the values there or set them to zero.

(In Drupal 7, this got simpler through the new drupal_set_time_limit() wrapper function, which will not call set_time_limit() at all if the current time limit is 0 (unlimited). To be exact, this works since Drupal 7.40, and before was prevented by issue #2233929.)

0

You can simply add sites/default/settings.php.

ini_set('max_execution_time', 0);

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.