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

Hallo Ingrid,

Wo ist der gespeichert? Unter phpinfo() hab ich auch nichts gefunden...

Hab jetzt mal nen Endlosschleife mit Ausgabe pro Sekunde hochgeladen um zu sehen wann es zu einer Fehlermeldung kommt - Problem dabei:

verwendest Du sleep()?
Wenn ja, dann ist Deine Messung wertlos, ich zitiere einen Benutzerkommentar zu sleep():

<zitat
    Note: The set_time_limit() function and the configuration directive
    max_execution_time only affect the execution time of the script itself.
    Any time spent on activity that happens outside the execution of the
    script such as system calls using system(), the sleep() function, database
    queries, etc. is not included when determining the maximum time that the
    script has been running.
</zitat>

jetzt hab' ich glatt vergessen, die Funktion ini_get() zu erwähnen ...
Welchen Wert Du übergeben musst, kannst Du dem Zitat entnehmen.

Freundliche Grüße

Vinzenz