Update auf Drupal 6.38 Datenbank Aktualisierungs-Script bricht ab
Eingetragen von Lissy01 (278)am 16.03.2016 - 11:00 Uhr in
Die Core-Dateien wurden upgedated.
Bei der Durchführung der update.php bricht das Script sofort ab und es bleibt der Bildschirm mit "Updating" beim Neüpunkt Run updates stehen.
Das Apache Error Log zeigt an, daß ein Server Limit überschritten wurde.
Die in Frage kommenden Werte (Memory, Exec. Time) stehen allerdings sehr hoch.
Das PHP-Log zeigt folgende Fehler an:
<?php
PHP Notice: unserialize() [<a href='function.unserialize'>function.unserialize</a>]: Error at offset 2 of 32 bytes in /xxx/includes/bootstrap.inc
PHP Parse error: syntax error, unexpected ':' in /xxx/includes/common.inc(1769) : eval()'d code on line 4
?>Der zweite kennzeichnet wohl nur den Ort des Abbuchs, es steht natürlich kein Doppelpunkt an dieser Stelle.
Mit dem ersten Fehler setze ich mich gerade näher auseinander und habe ermittelt, welche Variablen betroffen sind:
site_mail= s:35:"xxx@xxx.de";
drupal_http_request_fails= b:0;
pathauto_indexaliases= b:0;
pathauto_indexaliases_bulkupdate= b:0;
date_db_tz_support= b:0;
webform_default_from_address= b:0;
boost_loopback_bypass= b:0;
boost_crawl_url_alias= b:0;
devel_xhprof_enabled= b:0;
Ich sehe in alten Backups, daß die Variablen schon lange auf diesen Werten stehen - offensichtlich ohne negative Auswirkungen bei bisherigen Updates.
Nun wäre ich froh um jede Anregung, was ich noch unternehmen kann, um den Fehler zu lokalisieren.
Es geht darum, die Version 6 noch über einen gewissen Zeitraum lauffähig zu halten, bis der Relaunch fertig ist.
Könnte ich als Workarround die Datenbank-Aktualisierung per Hand vor nehmen?
- Anmelden oder Registrieren um Kommentare zu schreiben
Diese Variablen sind
am 16.03.2016 - 11:46 Uhr
Diese Variablen sind definitiv falsch gesetzt. Das Modul [do:variablecheck] gibt es erst ab Drupal 7. Dann bleibt nur, diese Variablen von Hand aus der variables-Tabelle der Datenbank zu löschen. Vorher unbedingt eine Sicherung der Datenbank anlegen.
Danke Werner... Ja, das
am 16.03.2016 - 13:27 Uhr
Danke Werner...
Ja, das händisch raus löschen wäre ja kein Problem.
Und dann? Werden die sauber wieder neu geschrieben beim Aufruf der Seiten?
Sicherung ist eh klar...
Diese Variablen sind
am 16.03.2016 - 13:45 Uhr
Diese Variablen sind Konfigurationsparameter von verschiedenen Modulen. Wenn Du bei diesen Modulen die Konfiguration aufrufst, prüfst und sicherst, werden die neu geschrieben.
OK danke, Werner, habe ich
am 16.03.2016 - 14:19 Uhr
OK danke, Werner, habe ich inzwischen alles gemacht und folglich wird auch die eine Fehlermeldung nicht mehr angezeigt.
Allerdings ändert das nichts an dem Einfrieren der update.php
Welche Ursachen könnte das noch haben?
Zwischenzeitlich habe ich die
am 18.03.2016 - 15:34 Uhr
Zwischenzeitlich habe ich die Datenbank bei mir lokal unter Windows / Apache nachgebaut.
Zwar gibt es die eine oder andere Fehlermeldung, weil hier bereits php 5.4 läuft, aber das Update läuft fehlerfrei durch und zeigt im Protokoll eine Alter Table auf die Session-Tabelle an.
Ist es möglich, daß memory_limit = 250MB und max_execution_time = 4400 nicht ausreichen für das Update-Script?
Diese Werte hat der Support des Hosters als gerade noch vertretbar für den Server genannt, um die Produkiv-Installation nicht zu beeinträchtigen.