l'empreinte mémoire d'un processus php laissé en tâche de fond augmente.
Quand un processus réclame de la mémoire au système il ne la rend jamais; c'est le cas de tous les processus, pas seulement ceux de PHP.
Donc à la fin de la journée, la mémoire occupée par tes processus PHP c'est MAX(mémoire occupée par les scripts exécutés)
Apache aussi a un MaxRequestsPerChild.
Je parlais de tous ces exploits qui ont permis la désactivation de l'open_basedir, du safe_mode, du disable_functions
Non tu disais que php n'était pas réentrant; je pense que tu mélanges pas mal de choses
Je parlais de tous ces exploits qui ont permis la désactivation de l'open_basedir, du safe_mode
En même temps ce sont des features dépréciées, il est recommandé de ne pas les utiliser.
J'avais lu un article à ce sujet (dans misc peut-être)
C'était peut être un article sur l'exploitation d'une faille en particulier. La faille a certainement été corrigée avant même la publication de l'article. Je suis sûr que je peux trouver un article sur l'exploitation d'une faille dans python, ruby, et tous les moteurs js.
Je parle aussi du fait que l'utilisation sur des serveurs en thread n'est pas possible
PHP est thread safe quand il est compilé avec l'option qui va bien. D'ailleurs c'est la seule manière d'utiliser PHP en tant que module IIS sous windows. (Certaines bibliothèques peuvent ne pas l'être par contre; ou des trucs comme putenv/getenv; mais rien de spécifique à PHP ici.)
Par contre il n'y a aucun intéret à utiliser des threads plutôt que des processus séparrés.
L'utilisation en event n'est pas possible non plus car le processus php ne peut rester en tâche de fond pour cause de gonflement de l'empreinte mémoire
C'est ton script qui fuit.
sous apache ça te sert une page et pas en fastcgi
ou l'inverse non ? si le module php crash, apache aussi, donc connexion terminée; si un process fastcgi crash, apache va retourner une error 500.
Et permet moi d'avoir un léger doute quand je vois comment un serveur http a été introduit à l'arache dans la sapi cli
C'est pour le dev, pas pour la prod.
Pourquoi tu veux absolument utiliser tous les trucs dépréciés / non recommandés en prod ?
[^] # Re: Pour compléter...
Posté par __o . En réponse à la dépêche État d'insécurité chez PHP. Évalué à 1.
Quand un processus réclame de la mémoire au système il ne la rend jamais; c'est le cas de tous les processus, pas seulement ceux de PHP.
Donc à la fin de la journée, la mémoire occupée par tes processus PHP c'est MAX(mémoire occupée par les scripts exécutés)
Apache aussi a un MaxRequestsPerChild.
Non tu disais que php n'était pas réentrant; je pense que tu mélanges pas mal de choses
En même temps ce sont des features dépréciées, il est recommandé de ne pas les utiliser.
C'était peut être un article sur l'exploitation d'une faille en particulier. La faille a certainement été corrigée avant même la publication de l'article. Je suis sûr que je peux trouver un article sur l'exploitation d'une faille dans python, ruby, et tous les moteurs js.
PHP est thread safe quand il est compilé avec l'option qui va bien. D'ailleurs c'est la seule manière d'utiliser PHP en tant que module IIS sous windows. (Certaines bibliothèques peuvent ne pas l'être par contre; ou des trucs comme putenv/getenv; mais rien de spécifique à PHP ici.)
Par contre il n'y a aucun intéret à utiliser des threads plutôt que des processus séparrés.
C'est ton script qui fuit.
ou l'inverse non ? si le module php crash, apache aussi, donc connexion terminée; si un process fastcgi crash, apache va retourner une error 500.
C'est pour le dev, pas pour la prod.
Pourquoi tu veux absolument utiliser tous les trucs dépréciés / non recommandés en prod ?