Javaprinter erzeugen viele php session files

[jori]

hallo,

Implementierung übersicht:
der javaprinter fragt regelmäßig die webapp ab. dabei sendet er keine session cookies mit. er braucht ja auch keine sessions.

die webapp verwendet php session handling, welche file-basiert ist im standardfall. dort wird entsprechend für jeden request, bei dem Informationen aus der session benötigt werden, session_start() aufgerufen und zwar wenn session_id() leer lieferte.

Das Problem ist:
auch die abfragen des javaprinter erreichen irgendwann diese code-stellen (session_start() aufruf, wenn session_id() leer) und erzeugen damit eine neue session, weil ja keine session-id (über cookie) mitgeschickt wurde.

das fällt bei standardeinstellungen (1440 s session timeout oder so) nicht weiter auf, da obwohl viele session files unnöitgerweise produziert werden, diese laufend auch wieder (weil alt) gelöscht werden.

Stellt man jetzt aber das session timeout auf einige Tage ein, dann sammeln sich durch die regelmäßigen abfragen der javaprinter sehr viele files an, welche unter entsprechenden umständen auch die inodes eines ext4 dateisystems aufbrauchen können. dann steht der server.

Lösung:
imo sollte man im falle des aufrufs durch einen javaprinter keine session erzeugen. sollte ja auch nicht notwendig sein, da eine neue session ja keine spezifischen daten beinhalten kann.
dh. entweder sind diese durch den javaprinter erreichten stellen mit session_start() nicht notwendig und session_start() sollte dort entfernt werden.
oder es sollte ein parameter mitübergeben werden, welcher bestimmt ob eine session angelegt werden soll, oder nicht. gibts noch eine lösung?

danke.

[pichel]

Hallo Jori,

danke für die Analyse. Das sollte natürlich nicht passieren, dass Aufrufe durch die Printserver einen Session starten. Ich bin aktuell nicht am Entwicklungsrechner, kann das also nicht prüfen. Aber wenn du schon so eine detaillierte Analyse gemacht hast, magst du mir vielleicht die Stelle(n) nennen, an der oder denen eine Session trotz Aufruf mit Authentifizierung über den Printcode gestartet wird? Wenn du es schon gefunden hast, kann ich mir die Zeit für die Suche sparen und diese lieber direkt in die Fehlerbehebung stecken.

Gruß,

Stefan

[jori]

hallo,

die verwendete version ist 1.5.7, sollte aber nach einem schnellen check auf bei den neueren versionen auftreten, da sich hier nichts grundlegendes verändert hat.
der javaprinter ruft contenthandler.php auf welches zB. module=printqueue.php (laut access logs) aufruft.
Dort

Code: Alles auswählen

$printQueue = new PrintQueue();
$printQueue->handleCommand($command);

command zB. "getNextFoodWorkPrintJobs"

Code: Alles auswählen

getNextFoodWorkPrintJobs()
....
....
--> saveLastPrintServerAccess()

saveLastPrintServerAccess() ruft dann date_default_timezone_set(DbUtils::getTimeZone()); auf.
und hier haben wir session_start().

Code: Alles auswählen

public static function getTimeZone() {
		if (is_null(self::$timezone)) {
			if(session_id() == '') {
				session_start();
			}
			if (isset($_SESSION['timezone'])) {
				return $_SESSION['timezone'];
			} else {
				return "Europe/Berlin";
			}
		} else {
			return self::$timezone;
		}
	}

Es gibt möglicherweise auch noch andere aufrufketten, bei denen irgendwann mal eine session erzeugt wird. Das hab ich aber nicht weiter geprüft.
kann natürlich sein, dass gerade hier immer self::$timezone gesetzt ist und damit session_start() gar nicht erfolgt .... der effekt ist aber vorhanden und von daher gehe ich davon aus, wenn nicht dieser Fall der auslöser ist, dann irgendeine andere aufrufkette.

getTimeZone() und saveLastPrintServerAccess() gibts unverändert auch in 1.5.29 , dh. auch dort sollte das problem auftreten.

Reproduzieren:
einen printer aktivieren und dann auf dem server /var/lib/php/session checken.
zB.
sudo watch "ls -1 /var/lib/php/session/ | wc -l" (oder so ähnlich, dann sieht man die wachsende anzahl an session files.

[jori]

vielleicht reicht es, wenn man, wenn man von einem javaprinter einstiegespunkt kommt, eine session manuell zu erzeugen mit session_start() mit der option session.save_handler="eigner save handler" (php bekannt gegeben per session_set_save_handler()) welcher die session gar nicht persistiert.

dann hätte man eine session, welche aber keine seiteneffekte hat.

könnte sein das es so reicht. ist aber nur eine lösungs möglichkeit, die man prüfen kann. Vorteil ist, dass man nicht alles session_start() aufruketten analysieren muß. eigentlich sollte imo aber die vom javaprinter aufgerufenen funktionen gar keine session mehr benötigen weil ja auch gar nicht mitgeliefert wird. das wäre die richtigere lösung.

[pichel]

Hallo Jori,

danke für das Beispiel. Die Erzeugung einer Session bei Aufruf von Methoden, die sich über den Printcode authentifizieren, ist definitiv nicht gewollt. Ich werde es mir, wenn ich wieder am Entwicklungsrechner bin, anschauen und gerade ziehen.

Schön, dass du mir mit der Nennung der Aufrufkette etwas Arbeit abgenommen hast.

Gruß,

Stefan

[jori]

da ich das problem schnell fixen wollte hab ich einen woraround eingebaut (vorher genauer geprüft, was der javaprinter aufruft, version 1.5.7):

nur verwendung durch javaprinter (um seiteneffekte auszuschliessen):

Code: Alles auswählen

/php/contenthandler.php?module=printqueue&command=getNextFoodWorkPrintJobs&printer=1&fl...
/php/contenthandler.php?module=printqueue&command=getNextDrinkWorkPrintJobs&printe....

/php/contenthandler.php?module=printqueue&command=getNextCancelFoodWorkPrintJobs&printer...
/php/contenthandler.php?module=printqueue&command=getNextCancelDrinkWorkPrintJobs&...

/php/contenthandler.php?module=printqueue&command=getNextClosingPrintJobs&...

/php/contenthandler.php?module=printqueue&command=getNextReceiptPrintJobs&language=....

/php/contenthandler.php?module=printqueue&command=deletePrintJob"....

von javaprinter aufgerufen, aber keine verwendung der Session:

Code: Alles auswählen

/php/contenthandler.php?module=printqueue&command=getLogoAsPng
/php/contenthandler.php?module=printqueue&command=getReceiptConfig

saveLastPrintServerAccess() benutzt die session, aber nur dort den fix anzubringen reichte nicht. scheint auch noch wanders eine session erzeugt zu werden. dh. bei allen diesen aufrufen hab als workaround immer die gleiche session_id erzeugt. damit wurden dann in der aufrufkette nicht immer wieder neue sessions erzeugt.

Code: Alles auswählen

printqueue PrintQueue
        /*
         * WORKAROUND:
         *
         * the javaprinter does not deliver a session id but some call chains
         * expect one resp. create one if a session is not available.
         * so create a fixed session here as a workaround instead of having to
         * touch every such place and correct it, to not expect a session!
         */
        private function createJavaprinterFixedSessionIdWorkaround(){
                session_id("fixedSessionIdForJavaprinter");
                session_start();
        }

[pichel]

Danke für die Analyse. Der javaprinter arbeitet übrigens intern ziemlich ähnlich wie der Windows-Printserver, sind also die gleichen Aufrufe.

Es ist natürlich ein Bug, dass in getTimeZone die Session abgefragt wird und in Abhängigkeit davon die Zeitzone zurückgegeben wird. Läuft die Installation in einer Zeitzone außerhalb Europe/Berlin, so würde dies wahrscheinlich dazu führen, dass der Benutzer immer die Druckerwarnung eingeblendet sieht.

Das werde ich auf jeden Fall in den nächste Tagen fixen und dann auch die anderen Stellen raussuchen.

Gruß,

Stefan

[pichel]

Hallo,

ich habe den Bug gefixt und die 1.5.33 veröffentlicht. Danke nochmals an jori!

Einige Nutzer hatten mir in der Vergangenheit berichtet, dass zum Tagesende die Performance sank. Die Ursache könnte auch an diesem Bug gelegen haben, so dass betroffene Anwender auf die 1.5.33 updaten sollten.

Gruß,

Stefan

[jori]

danke für den schnellen fix.