Ce script la à un bug en plus. Si tu utilises docker, alors les processus dans le container sont visibles de l'extérieur.
Exemple:
$ docker run -i -t ubuntu /bin/bash
# vi
et sur un autre terminal:
$ ps fax | grep -A 2 /bin/docker
13583 ? Ssl 0:00 /usr/bin/docker -d
14007 pts/3 Ss 0:00 \_ /bin/bash
14054 pts/3 S+ 0:00 \_ vi
Donc "killall vi" en root lancé en dehors du docker va tuer le processus vi dans le container docker ( ie, du lxc tout con ).
Si tu remplaces vi par httpd, tu as un bug, sauf à vouloir que ton script httpd externe tue le processus qu'il lance et celui lancé ailleurs.
Et je passe sur le fait que httpd peut aussi lancer des processus qui s'appelle pas "httpd", au hasard, tout les processus wsgi lancé par mod_wsgi, et qu'ils vont totalement être oublié en cas de problème par le "killall httpd". IE, le nettoyage est incomplet.
Ensuite, dans l'action restart, le signal envoyé par le script est SIGTERM. Ce qui veut dire qu'un processus peut l'ignorer et/ou ne pas le traiter à temps, et donc que apache peut continuer de tourner, ce qui fait que le démarrage va échouer. Bien sur, jamais apache n'est surchargé et jamais il ne va mettre trop longtemps à mourir. Et jamais personne ne va injecter du code dans un processus apache via un interpréteur embarqué php. Car bon, tout le monde a retiré mod_php, qui tourne dans le même espace mémoire qu'apache par design, non ?
(et je parle pas d'attaque sr le code de php, je parle d'une personne qui va utiliser pcntl_signal en php dans une page pour dire à apache d'ignorer SIGTERM ou ce genre de trucs crades. J'ai pas testé, mais je serais pas étonné que ça marche).
Mais bon, j'imagine que "utiliser des containeurs" et "avoir des processus apache qui partent modérément en sucette" arrive pas si souvent, c'est juste la faute à pas de chance, et qu'on peut continuer à garder des scripts rempli de boilerplates et de bugs parce que c'est mieux (tm) ?
[^] # Re: USE="-systemd"
Posté par Misc (site web personnel) . En réponse au journal Chronique des dinosaures rétrogrades. Évalué à 7.
En effet, voir ce thread :
https://linuxfr.org/users/claudex/journaux/chronique-des-dinosaures-retrogrades#comment-1534946
Ce script la à un bug en plus. Si tu utilises docker, alors les processus dans le container sont visibles de l'extérieur.
Exemple:
et sur un autre terminal:
Donc "killall vi" en root lancé en dehors du docker va tuer le processus vi dans le container docker ( ie, du lxc tout con ).
Si tu remplaces vi par httpd, tu as un bug, sauf à vouloir que ton script httpd externe tue le processus qu'il lance et celui lancé ailleurs.
Et je passe sur le fait que httpd peut aussi lancer des processus qui s'appelle pas "httpd", au hasard, tout les processus wsgi lancé par mod_wsgi, et qu'ils vont totalement être oublié en cas de problème par le "killall httpd". IE, le nettoyage est incomplet.
Ensuite, dans l'action restart, le signal envoyé par le script est SIGTERM. Ce qui veut dire qu'un processus peut l'ignorer et/ou ne pas le traiter à temps, et donc que apache peut continuer de tourner, ce qui fait que le démarrage va échouer. Bien sur, jamais apache n'est surchargé et jamais il ne va mettre trop longtemps à mourir. Et jamais personne ne va injecter du code dans un processus apache via un interpréteur embarqué php. Car bon, tout le monde a retiré mod_php, qui tourne dans le même espace mémoire qu'apache par design, non ?
(et je parle pas d'attaque sr le code de php, je parle d'une personne qui va utiliser pcntl_signal en php dans une page pour dire à apache d'ignorer SIGTERM ou ce genre de trucs crades. J'ai pas testé, mais je serais pas étonné que ça marche).
Mais bon, j'imagine que "utiliser des containeurs" et "avoir des processus apache qui partent modérément en sucette" arrive pas si souvent, c'est juste la faute à pas de chance, et qu'on peut continuer à garder des scripts rempli de boilerplates et de bugs parce que c'est mieux (tm) ?