4.5.2 alpha: Time-Out-Problem

[m.wohlers]

Hallo!

Ich nutze den aktuellen Snapshot der Contenido 4.5.2 alpha (contenido-cvs-45-2004-07-16.tar.bz2) und habe folgendes Problem:

bei drei verwalteten Mandanten passiert es in unregelmäßigen Abständen und Situationen, daß vom ausgewählten Mandant in den Standard-Mandent zurückgewechselt wird. Z.B. nach dem Ändern eines Layouts (was einwandfrei funktioniert) sieht man links in der Navigation die Layouts des Standard-Mandanten, obwohl im rechten Frame das aktuelle Layout offen ist. Klickt man dann auf "Vorschau" gibt's Fehler...

Leider kann ich den Bug nicht so reproduzieren, daß daraus eine "Drücke x und es passiert y"-Beschreibung entsteht, aber er tritt häufig auf.

[emergence]

meinst du wenn du den 3 mandanten bearbeitest, das er zu den ersten mandanten springt (beim editor allgemein)?
oder tritt das nur bei einer style-layout änderung beim 3 mandanten auf ?

[m.wohlers]

Hallo Emergence!

meinst du wenn du den 3 mandanten bearbeitest, das er zu den ersten mandanten springt (beim editor allgemein)?
oder tritt das nur bei einer style-layout änderung beim 3 mandanten auf ?

Sorry, war wegen Urlaub nicht erreichbar...

Es tritt bei verschiedenen Funktionen auf, daß irgendwie intern zum ersten Mandanten "zurückgewechselt" wird. Wie ich es beschrieben habe, ist im Main-Frame dann zwar wie gewünscht z.B. das Layout vom dritten (eigentlich aktuellen) Mandanten zu sehen, in der Navigation links kommt jedoch die Information vom ersten Mandanten und bei der nächsten Aktion kommt dann ein Fehler, da sich Contenido nicht mehr auskennt...

[timo]

Gibts eine "Anleitung", wie man das nachvollziehen kann?

[m.wohlers]

Hallo Timo!

Gibts eine "Anleitung", wie man das nachvollziehen kann?

Ich hatte gehofft, daß meine Darstellung bildlich genug war... aber noch ein Versuch:

Ich habe drei Mandanten eingerichtet. Ich gehe in's Backend von Contenido und wähle dort z.B. den dritten Mandanten aus, um dort zu arbeiten.

Dann gehe ich in "Style -> Layouts" und wähle dort ein Layout aus. Wenn ich jetzt im RECHTEN Frame Änderungen am Layout durchführe und den grünen "Änderungen speichern"-Button drücke, dann werden die Änderungen ordnungsgemäß gespeichert. Allerdings erscheinen danach in dem LINKEN Frame mit der Liste an vorhandenen Layouts diejenigen für Mandant 1, und im RECHTEN Frame sehe ich das zuletzt bearbeitete Layout aus Mandant 3.

Irgendwie wurde also NACH dem Bearbeiten des Layouts in den Mandant 1 zurückgesprungen. Wenn ich versuche, weiterzuarbeiten, erhalte ich Fehler und muß also manuell wieder auf Mandant 3 umwechseln. Das taucht sporadisch auf, ich kann keine Regelmäßigkeit erkennen, pro Stunde aber sicher 3-4 mal bei meinem Produktiveinsatz. Einträge im ErrorLog gibt es keine.

Ich werde demnächst auf den aktuellen Snapshot "contenido-cvs-2004-08-10" wechseln, vielleicht habe ich da anderes Verhalten, das werde ich prüfen und ggf. hier posten.

Für weitere Fragen... her damit!

[m.wohlers]

Hallo Timo!

Also, auch mit dem brandneuen Snapshot (contenido-cvs-2004-08-13.tar.bz2) hat sich nichts am Verhalten geändert.

Mein Vorgang, der soeben zum beschriebenen Fehler führte: Änderungen an einem Modul gemacht, anschließend auf "Content -> Artikel" gewechselt - und der Kategorie-Baum erschien leer. Im "MyContenido" war wieder zu sehen, daß Mandant Nr. 1 aktiv war - obwohl ich vorher im dritten Mandanten aktiv war.

Falls es von Belang ist:

Code: Alles auswählen

Anzahl Benutzer 3 
Anzahl der Artikel 42 
Server operating system Apache/1.3.31 (Unix) FrontPage/5.0.2.2635 PHP/4.3.8 
MySQL Serverversion 4.0.20-log 
Installierte PHP-Version 4.3.8 
safe_mode deactivated 
magic_quotes_gpc Aktiviert 
magic_quotes_runtime deactivated 
gpc_order GPC 
memory_limit 16M 
max_execution_time 30 
Deaktivierte Funktionen nothing disabled 
Gettext extension geladen 
sql.safe_mode deactivated 
GD library Einstellungen Werte 
GD Support  enabled  
GD Version  bundled (2.0.23 compatible)  
FreeType Support  enabled  
FreeType Linkage  with freetype  
GIF Read Support  enabled  
JPG Support  enabled  
PNG Support  enabled  
WBMP Support  enabled  
XBM Support  enabled  
 
include_path ./:/usr/share/pear/ 

Any ideas?

[timo]

Nein leider nicht...das Phänomän haben wir mittlerweile auch, aber niemand weiß, wo es herkommt...vor allem, weil es scheinbar "zufällig" auftritt

[m.wohlers]

Hallo timo!

Nein leider nicht...das Phänomän haben wir mittlerweile auch, aber niemand weiß, wo es herkommt...vor allem, weil es scheinbar "zufällig" auftritt

Aber Ihr könnt es auch beobachten, oder? Sorry daß ich frage, aber manchmal fühlt man sich wie im falschen Film, wenn alle sagen "also hier können wir das nicht nachvollziehen"

[timo]

ja woher das kommt weiß niemand, und auch nicht, wie man es reproduzieren kann...

[timo]

Ich glaube, wir haben das ganze jetzt gefunden Allerdings eher durch Zufall....hier die Lösung:

Mandantenwechsel-Bug
--------------------

Bugbeschreibung

Der Bug entsteht durch eine Verkettung von Ereignissen. Zum einen wird in einem fehlerhaften Cronjob (send_reminder.php) der Wert für den aktuellen Mandanten gesichert, aber noch bevor dieser aus dem globalen Kontext initialisiert wurde (=ein nichtgesetzter Wert wird gespeichert). Am Ende des Cronjobs wird der gespeicherte Wert zurückgesichert, der dann jedoch immer noch leer ist. Im Regelfalle bleibt das Problem unbemerkt, wenn die Cronjobs schnell genug durchlaufen (sie werden nur im Frame 1 im Backend ausgeführt) und eine andere Seite nach Frame 1 seine Daten in die Session sichert (das wechseln des Mandanten betrifft dann nur Frame 1, welches in den meisten Fällen unbemerkt bleibt).

Benötigt aber der Cronjob, der in Frame 1 getriggert wurde, länger als alle anderen Cronjobs, so werden die Session-Daten von Frame 1 auch in die Datenbank gesichert und überschreiben damit den Mandanten, welches sich allerdings erst beim nächsten Laden einer Backend-Seite auswirkt.

Lösung

Die Lösung ist einerseits ein Patch im Cronjob "send_reminder.php", als auch in der Sicherstellung, daß globale Systemvariablen nicht durch cronjobs überschrieben werden können. Änderung in der send_reminder.php:

Code: Alles auswählen

$oldclient = $client;

global $cfg, $client;

wird zu

Code: Alles auswählen

global $cfg, $client;

$oldclient = $client;

In der pseudo-cron.inc.php wird

Code: Alles auswählen

chdir($PC_jobDir);
$PC_jobs = parseCronFile($PC_cronTab, $PC_debug);
for ($i=0;$i<count($PC_jobs);$i++) {
  	runJob($PC_jobs[$i], $PC_jobDir, $PC_writeDir, $PC_useLog, $PC_debug);
}
$PC_jobs = parseCronFile($PC_localCronTab, $PC_debug);
for ($i=0;$i<count($PC_jobs);$i++) {
   	runJob($PC_jobs[$i], $PC_jobDir, $PC_writeDir, $PC_useLog, $PC_debug);
}

zu

Code: Alles auswählen

$bJobRunned = false;

chdir($PC_jobDir);
$PC_jobs = parseCronFile($PC_cronTab, $PC_debug);
for ($i=0;$i<count($PC_jobs);$i++) {
	$bJobRunned = true;
   	runJob($PC_jobs[$i], $PC_jobDir, $PC_writeDir, $PC_useLog, $PC_debug);
}
$PC_jobs = parseCronFile($PC_localCronTab, $PC_debug);
for ($i=0;$i<count($PC_jobs);$i++) {
	$bJobRunned = true;
   	runJob($PC_jobs[$i], $PC_jobDir, $PC_writeDir, $PC_useLog, $PC_debug);
}

In der main.php wird

Code: Alles auswählen

    if ($frame == 1)
    {
        $oldpwd = getcwd();
        chdir($cfg["path"]["contenido"].$cfg["path"]["cronjobs"]);
        cInclude("includes", "pseudo-cron.inc.php");
        chdir($oldpwd);
    }

zu

Code: Alles auswählen

    if ($frame == 1)
    {
        $oldpwd = getcwd();
        chdir($cfg["path"]["contenido"].$cfg["path"]["cronjobs"]);
        cInclude("includes", "pseudo-cron.inc.php");
        chdir($oldpwd);
        
        if ($bJobRunned == true)
        {
        	/* Some cronjobs might overwrite important system variables.
        	 * We are thaw'ing the session again to re-register these variables.
        	 */
        	$sess->thaw();	
        }
    }

[m.wohlers]

Hallo timo!

Ich glaube, wir haben das ganze jetzt gefunden Allerdings eher durch Zufall....hier die Lösung:

Mandantenwechsel-Bug
--------------------

Ich liebe Euch alle... Fast zu schön, um wahr zu sein, aber zu einfallslos für einen Faschingscherz...

Sollte ja dann im nächsten Snapshot drinnen sein, oder? Gibt es am Freitag wieder einen aus dem (neuen) CVS oder dauert das noch länger?

Fröhliche Grüsse aus dem verschneiten Oberbayern...

[timo]

Ich liebe Euch alle... Fast zu schön, um wahr zu sein, aber zu einfallslos für einen Faschingscherz...

Wenn es ein Scherz wäre, hätte ich bestimmt nicht gestern "Hab ich dich du scheiss-Bug" hier im Büro herumgebrüllt

Sollte ja dann im nächsten Snapshot drinnen sein, oder? Gibt es am Freitag wieder einen aus dem (neuen) CVS oder dauert das noch länger?

Ausnahmsweise gibts den schon morgen, aber danach wieder wöchentlich.

[m.wohlers]

Hi timo!

Ich liebe Euch alle... Fast zu schön, um wahr zu sein, aber zu einfallslos für einen Faschingscherz...

Wenn es ein Scherz wäre, hätte ich bestimmt nicht gestern "Hab ich dich du scheiss-Bug" hier im Büro herumgebrüllt

Gibt es eine Webcam aus Deinem Büro? Wenn nein, bitte unbedingt installieren, ist fast so wichtig wie die wöchentlichen Snapshots

Sollte ja dann im nächsten Snapshot drinnen sein, oder? Gibt es am Freitag wieder einen aus dem (neuen) CVS oder dauert das noch länger?

Ausnahmsweise gibts den schon morgen, aber danach wieder wöchentlich.

Thx... heute Abend? morgen Abend? Anyway, ich schau's mir an...

Grüsse...

[timo]

Thx... heute Abend? morgen Abend? Anyway, ich schau's mir an...

Also rein technisch gesehen wird der Snapshot um 23 Uhr erzeugt, je nachdem, wie lange der Server braucht, liegt er dann entweder heute (vor 0 Uhr) oder morgen (nach 0 Uhr) vor

[emergence]

um nur kurz auf den bug zurück zu kommen

wie wäre es mit der option zu beginn des cronjobs alle variablen zu sichern mittels
$sess->freeze();
und anschließend nach den cronjobs mittels
$sess->thaw();
wieder neu zu laden... (so wie du es oben bereits machst)

sollte eventuell ja auch funktionieren...
dann sollte es ziemlich egal sein welche variablen der cronjob ändert...