Pour le sleep, il repose sur le SIGALRM tout comme max_execution_time, donc le handler du signal est détourné ce qui explique ce comportement. Si tu as un accès à un serveur web Apache avec module PHP, un bot ferait l’affaire pour le griller :)

Avec un shell_exec c’est la même chose. Par contre, tu peux avoir une erreur fatale au niveau de l’allocation mémoire. Exemple: shell_exec(‘/usr/bin/yes’).

La commande timeout est à utiliser avec les shell_exec. Mais au niveau cron, je préfère une autre solution, à savoir restreinte et transparente car il vaut mieux donner aucune confiance à l’utilisateur. Je vais voir du côté des cgroups (http://www.mjmwired.net/kernel/Documentation/cgroups/cpuacct.txt). Si j’ai des news je posterais mes résultats. Cf mon article pour une configuration sécuriée en mode FPM avec des cgroups sur la RAM et le % CPU : http://blog.hbis.fr/2012/01/16/debian-webserver_and_cgroups/

timeout 10 php script.php

et même possibilité de spécifier le type de signal à envoyer. S’il n’y a aucune conséquence au kill bête et méchant, why not?

Une autre solution, register_shutdown_function() et error_get_last() dedans pour vérifier que le script ne s’est pas arrêté pour cause de timeout. Cette manip me semble plus aléatoire cependant, pour la remarque d’utilisation CPU en rapport avec set_time_limit (un sleep(30) sur un max_execution_time de 10 n’amènera jamais à l’erreur de timeout…)

3. je n’ai pas potassé le sujet des timeout jusqu’à ce niveau, mais ta remarque est aussi évidente qu’en 1.

4. C’est parce que tes articles sont trop courts! Alors lâchons nous dans les commentaires! :)

Fonction à bannir d’emblée : set_time_limit. Quand je configure php-fpm je restreins de toute manière le max_execution_time à 30 s (merci php_admin_value) et je force en plus le kill du script avec request_terminate_timeout à 35 s. Pour les crons, je ne connais pas de solutions. A voir du côté des cgroups Linux ?

Au niveau MySQL, tu peux gérer les timeout de connexion, net_read_timeout, net_write_timeout, wait_timeout et innodb_lock_wait_timeout. Reste évidemment que le temps de processing d’une query n’a pas de timeout. D’où l’intérêt d’une bonne structure et des requêtes précises.

Tu me fais trop parler Ludovic, c’est pas bien !

Ceci dit, un peu de lecture de la doc PHP mentionne que:

« Any time spent on activity that happens outside the execution of the script such as system calls using system(), stream operations, database queries, etc. is not included when determining the maximum time that the script has been running. »

(http://www.php.net/manual/en/function.set-time-limit.php)

Alors, ce comportement est-il bien ou pas est une autre question, mais au moins, il est documenté.

Si c’est lancé en cron, attention au PATH & permissions.

Avez-vous une suggestion?

usage: mktemp [-d] [-q] [-t prefix] [-u] template …
mktemp [-d] [-q] [-u] -t prefix
/Applications/assp/assp-stat/zabbix-postfix.sh: line 21: 1: ambiguous redirect
File /tmp/zabbix-postfix-offset.dat cannot be created. Check your permissions.
usage: rm [-f | -i] [-dPRrvW] file …
unlink file

Pardon pour la multiplication des posts