nicht angemeldet
Hello,
Was spricht dagegen, solche langen Scriptlaufzeiten zuzulassen?
Der Server wird mit der Rechenzeit belastet.
Es könnten ungewollte Endlosschleifen in einem Script enthalten sein oder Aufrufe auf z.B. externe Ressourcen, die kein Timeout haben, ein Datenbank-Deadlock oder ähnliches.
Ein Script sollte daher eine angemessene, aber keine endlose Laufzeit erhalten.
Je nach Einstellung von http://de3.php.net/manual/en/function.ignore-user-abort.php würde ein solches Script dann nämlich zum Zombie werden können.
Man sollte daher Scripte, die mit längerem oder deaktivierten Timeout gestartet werden, auf andere Weise unter Kontrolle behalten. Z.B., indem sich diese Scripte mit ihrer PID in eine Tabelle eintragen und solange sie laufen, immer mal wieder einen Timestamp aktivieren oder indem sie nur weiterlaufen, solange ein PID-Kontrollfile vorhanden ist.
Mittels Zusatzscript kann man dann durchgedrehte Kandidaten wieder entfernen lassen.
Wie verhält es sich mit Sessions - sind die trotzdem nach einer solchen Zeit noch gültig oder verlieren die Ihre Gültigkeit?
Sessions sind gerade dafür gemacht, dass sie die Laufzeit mehrerer aufeinanderfolgender und terminierender Scripte überleben und so die Daten von einem zum anderen Script weiterreichen können. Sessions haben bei PHP eine Mindestlebensdauer, die fälschlicherweise mit dem Konfigurationswert session.max_lifetime eingestellt wird. Bei Debian-Installationen werden die Sessions von Cron-Jobs bereinigt, was dann auch zu einer relativ genauen Einhaltung der nicht nachgetriggerten Lebensdauer führt, bei vielen anderen Installationen werden sie vom PHP-eigenen Garbage Collector bedient, der aber per Statistischem Wert zuschlägt. Je intensiver das System benutzt wird, desto genauer wird die Restlebensdauer eingehalten.
Ist eine so lange Scriptlaufzeit ein Sicherheitsrisiko?
Im Prinzip nicht, wenn das Script bezüglich Race-Conditions vernünftig geschrieben ist.
Wenn man in einem solchen Scripte allerdings eine Session öffnet, bleibt die für andere Scripte solange gesperrt, bis dieses erste terminiert. Man müsste also die Sessiondatei innerhalb des Scriptes gezielt freigeben, solange man sie nicht selber benötigt. Das ganze wird dann irgendwann schon recht komplex. Kurze Laufzeiten sind daher empfehlenswert.
Wie verhällt es sich mit dem Server - ist es rechenintensive ein Script so lange laufen zu lassen?
Der teilt allen Programmen eine gewisse Zeit zu, je nach Priorität usw.
Irgendwann hat er noch nicht einmal mehr genügend Zeit, um die Register (LDT) zu sichern/wiederherzustellen und schmiert ab.
Liebe Grüße
Tom vom Berg
Nur selber lernen macht schlau