Improve cron updates

"MySQL server has gone away" should have no relation to how this module operates, I think it was triggered by some other issue. Can you still reproduce this reliably?

Looks like the answer is no.

Hi,
I'll reopen this issue because I'm getting exactly the same error, every time I try to visit admin/reports/status or admin/config. The page loads for a every long time and in the end some kind of timeout causes the error message above...

This problem is a real big question mark for me. First I thought that perhaps the module tries to load a language file from a remote server and has connection problems and causes a timeout, but there's no call like this on line 399, only a db query. And this query is very normal and harmless:
$result = db_query("SELECT * FROM {l10n_update_file}");

I also looked at the database table. There are currently 24 records in it. All of them look normal - no duplicates, nothing suspicious there.

As soon as I disable the l10n module, everything works perfectly. As soon as I enable it, the problem reappears.

Further important infos:

1. This is not the only site where I experienced this problem. It's already the 3rd or 4th in the past days
2. The problem happens not all the time. It only lasts for a certain period of time. After that it may disappear, but also possibly reappear again.

Especially the last info, that it is reproducible, but only for a certain amount of time, brings me to the idea, that maybe a bad record in a cache table may be the cause?!

When I look at the 'cache' table, I see a record with cid 'l10n_update_server:http://localize.drupal.org/l10n_server.xml' . I tried to delete that record, but the error still remains...

Same problem since 09/22/2011

Had same problem. Got rid of it after disabling "Localization update" module.

The same problem - when I disabled the l10n module everything works fine.

In my experience the "MySQL server has gone away" error is a combination of slow sever, minimal database settings, many modules and heavy task. Many of these are beyond our control as module maintainer. Probably the only thing we can do is to cut down the download and import task into smaller portions. That's why we should postpone this issue until #569004: Add support for seek based batch import of .po files is fixed.

Same issue here, since 3 Days i get this message. It really looks like its a server issue. I've mirrored my site on my developing machine and here it works. I've tried to increase some PHP limits on my server

php_value mysql.connect_timeout 1800
php_value max_execution_time 1800
php_value default_socket_timeout 1800

but this doesnt help.

Maybe its a good workaround, if there exists some options to select which Modules should be automaticaly updated. Unfortunately i'm not familiar enough with Drupal to submit a patch.

This happens if you got plenty of modules to check.

l10n_update_requirements() calls l10n_update_available_releases() which always calls l10n_update_check_projects() if cache for cache_get('l10n_update_available_releases') is not built, no matter what $frequency is set to.

l10n_update_check_projects() is quite heavy for multiple projects. A temporary fix is increasing the execution time limit during this checking process. Note this process is only invoked if there is no cache yet.
l10n_update.check.inc

function l10n_update_check_projects($projects, $languages = NULL, $check_local = TRUE, $check_remote = TRUE) {
  $languages = $languages ? $languages : array_keys(l10n_update_language_list());
  $result = array();
  foreach ($projects as $name => $project) {
    foreach ($languages as $lang) {
      set_time_limit(30); // <-- Add this as a temporary fix.
      $source = l10n_update_source_build($project, $lang);
      if ($update = l10n_update_source_check($source, $check_local, $check_remote)) {
        $result[$name][$lang] = $update;
      }
    }
  }
  return $result;
}

A real fix would be following the same procedure as Update module from core; reporting that no update information is available and refactoring l10n_update_check_projects() into a batch.

You are right, we don't do temporary fixes ;) I was working myself through the same part of code while working on issue: #1347440: l10n_update_requirements() in manual mode
At first l10n_update_check_projects() should respect the manual/frequency setting. Next need to check if recently collected states can be re-used and lastly we should use batch api where possible. But the same function must be usable in both cron and UI conditions.

Rewriting the status update process to a batch process turns out to be a major operation. For now I will postpone this issue until we see the results of #1347440: l10n_update_requirements() in manual mode. This should result in a less frequent use of the update status process.

@casey, can you help on this conversion to a batch process?

The introduction of a batch process for status check takes place here: #1430546: Better performance when fetching available update status

I am really sorry but I currently just have no time.

Hi all! I ran into the very same problem! Pointing to /admin/reports/status I wait for long then I get this error

Additional uncaught exception thrown while handling exception.

Original

PDOException: SQLSTATE[HY000]: General error: 2006 MySQL server has gone away: SELECT * FROM {l10n_update_file}; Array ( ) in l10n_update_get_history() (line 428 of /home/sideoffc/public_html/sites/all/modules/l10n_update/l10n_update.module).

Additional

PDOException: SQLSTATE[HY000]: General error: 2006 MySQL server has gone away: INSERT INTO {watchdog} (uid, type, message, variables, severity, link, location, referer, hostname, timestamp) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4, :db_insert_placeholder_5, :db_insert_placeholder_6, :db_insert_placeholder_7, :db_insert_placeholder_8, :db_insert_placeholder_9); Array ( [:db_insert_placeholder_0] => 1 [:db_insert_placeholder_1] => php [:db_insert_placeholder_2] => %type: !message in %function (line %line of %file). [:db_insert_placeholder_3] => a:6:{s:5:"%type";s:12:"PDOException";s:8:"!message";s:109:"SQLSTATE[HY000]: General error: 2006 MySQL server has gone away: SELECT * FROM {l10n_update_file}; Array ( ) ";s:9:"%function";s:25:"l10n_update_get_history()";s:5:"%file";s:75:"/home/sideoffc/public_html/sites/all/modules/l10n_update/l10n_update.module";s:5:"%line";i:428;s:14:"severity_level";i:3;} [:db_insert_placeholder_4] => 3 [:db_insert_placeholder_5] => [:db_insert_placeholder_6] => http://battuage.info/admin/reports/status [:db_insert_placeholder_7] => [:db_insert_placeholder_8] => 93.57.77.58 [:db_insert_placeholder_9] => 1342874196 ) in dblog_watchdog() (line 154 of /home/sideoffc/public_html/modules/dblog/dblog.module).

Uncaught exception thrown in shutdown function.

PDOException: SQLSTATE[HY000]: General error: 2006 MySQL server has gone away: DELETE FROM {semaphore} WHERE (value = :db_condition_placeholder_0) ; Array ( [:db_condition_placeholder_0] => 1352671833500aa254876858.50420914 ) in lock_release_all() (line 269 of /home/sideoffc/public_html/includes/lock.inc).

Same on /admin/config/regional/translate/update:

Additional uncaught exception thrown while handling exception.

Original

PDOException: SQLSTATE[HY000]: General error: 2006 MySQL server has gone away: SELECT s.lid, t.translation, s.version FROM {locales_source} s LEFT JOIN {locales_target} t ON s.lid = t.lid AND t.language = :language WHERE s.source = :source AND s.context = :context AND s.textgroup = 'default'; Array ( [:language] => it [:source] => Select one or more languages to download and update. If you select none, all of them will be updated. [:context] => ) in locale() (line 684 of /home/sideoffc/public_html/modules/locale/locale.module).

Additional

PDOException: SQLSTATE[HY000]: General error: 2006 MySQL server has gone away: INSERT INTO {watchdog} (uid, type, message, variables, severity, link, location, referer, hostname, timestamp) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4, :db_insert_placeholder_5, :db_insert_placeholder_6, :db_insert_placeholder_7, :db_insert_placeholder_8, :db_insert_placeholder_9); Array ( [:db_insert_placeholder_0] => 1 [:db_insert_placeholder_1] => php [:db_insert_placeholder_2] => %type: !message in %function (line %line of %file). [:db_insert_placeholder_3] => a:6:{s:5:"%type";s:12:"PDOException";s:8:"!message";s:469:"SQLSTATE[HY000]: General error: 2006 MySQL server has gone away: SELECT s.lid, t.translation, s.version FROM {locales_source} s LEFT JOIN {locales_target} t ON s.lid = t.lid AND t.language = :language WHERE s.source = :source AND s.context = :context AND s.textgroup = 'default'; Array ( [:language] => it [:source] => Select one or more languages to download and update. If you select none, all of them will be updated. [:context] => ) ";s:9:"%function";s:8:"locale()";s:5:"%file";s:55:"/home/sideoffc/public_html/modules/locale/locale.module";s:5:"%line";i:684;s:14:"severity_level";i:3;} [:db_insert_placeholder_4] => 3 [:db_insert_placeholder_5] => [:db_insert_placeholder_6] => http://battuage.info/admin/config/regional/translate/update [:db_insert_placeholder_7] => http://battuage.info/ [:db_insert_placeholder_8] => 93.57.77.58 [:db_insert_placeholder_9] => 1342874268 ) in dblog_watchdog() (line 154 of /home/sideoffc/public_html/modules/dblog/dblog.module).

Uncaught exception thrown in shutdown function.

PDOException: SQLSTATE[HY000]: General error: 2006 MySQL server has gone away: DELETE FROM {semaphore} WHERE (value = :db_condition_placeholder_0) ; Array ( [:db_condition_placeholder_0] => 837158220500aa29c3b7ac7.09311351 ) in lock_release_all() (line 269 of /home/sideoffc/public_html/includes/lock.inc).

Uncaught exception thrown in session handler.

PDOException: SQLSTATE[HY000]: General error: 2006 MySQL server has gone away in _drupal_session_write() (line 209 of /home/sideoffc/public_html/includes/session.inc).

same issue here

Subscribing.

Does anyone know any workaround?

@trainingcity, no there is no solution unless someone is working on it.
Back to postponed.

This seem to be a workaround for the localization/mysql issue

https://drupal.org/node/259580#comment-1511512

Updated issue summary.

No further development on 7.x-1.x branch will take place for this issue. 7.x-2.x branch has an improved cron handling.