Non la c'est pas gentil Lighttpd, vraiment

Je m'explique...

J'ai mon process à moi, indépendant, qui gère le protocole FastCGI.
J'ai ma config:



Il a à priori pas besoin de plus et en effet, il se connecte, récupère et affiche la page sans soucis, sauf que juste après avoir envoyé la page, ce con suspend mon processus et je dois manuellement faire un fg %1 pour le relancer.

Bref, pas du tout pratique pour un serveur web si je dois manuellement lancer le truc page par page

Any idea?
phil?

C'est quel process qui est suspendu ? Ton fastcgi ? Tu l'as démarré en background ? Et il utilise stdin/stdout/stderr ?

Si tu le laisses en foreground que fait-il ?

C'est mon process fastcgi que j'ai démarré manuellement, en foreground!, que Lighttpd suspend.

Je recois un

[1]+ Stopped ./kelare

Et si je refais un fg %1 ca repart pour un tour et il me refait la même chose... J'ai tenté de bloquer une dizaine de SIG déjà sans trouver le bon

faut pas bloquer les signaux, faut les intercepter ...

SIGSTOP ne peut être ni bloqué, ni traité.
Faudrait trouver pourquoi lighttpd envoie ce signal au process fastcgi, ce qui semble être le cas...

Je cherche sur google...

... je trouve des bug reports php (http://www.google.be/search?hl=en&q=sigstop++fastcgi&btnG=Search&meta=), mais le site bugs.php.net ne répond pas chez moi pour l'instant...

Il est écrit en PHP to process fastcgi ?

Non, il est écrit en Pascal (Kylix) et je sais intercepter une bonne partie des signaux, mais en effet si c'est un SIGSTOP que ce connard envoie j'ai aucune chance de le bloquer

Fait chier, maintenant que j'ai plus de SegFault ce serait bien qu'on me tue pas unilatéralement mon process

http://groups.google.be/group/mailing.www.php-dev/browse_thread/thread/aab7bdaef0d3fac0/4d220c53540963ef?lnk=st&q=sigstop++li- ghttpd&rnum=1&hl=en#4d220c53540963ef

C'est strace qui me permet de savoir quel message j'ai reçu? J'aimerais être sûr déjà que je reçois un SIGSTOP et de qui

Ah... J'ai lancé strace et je vois un:

ERESTART_RESTARTBLOCK (To be restarted)

Bon vais chez brico, je note ça pour plus tard, ça doit bien avoir une raison ce truc

Ce serait lié à une boucle avec un... Sleep(1) et un nanosleep qui fail

Ptain c'est quoi ce bordel

Bon tant pis, Brico, j'espère que ca tournera pas trop tard ce truc, c'était pas un bug prévu au planning

Bon non c'est pas le nanosleep, dommage... En virant le sleep et en relancant avec un strace il ne me dit rien du tout mais le process est quand même down

Non di djou

Courage tu vas trouver

Tu vas le mater ce fastcgi

Quels libs utilises-tu dans ton prog fastcgi ? Une lib fastcgi ? Un accès DB ?
C'est peut-être une autre cause que lighttpd lui-même...

Tout est codé à la main, pas question d'utiliser une lib fastcgi non

Mais pourquoi ce serait à la fin de la requête fastcgi exactement que le process est foutu en suspend et que si je le relance manuellement il recommence parfaitement pour la prochaine requête, etc, etc?

Y a vraiment aucune raison

ben file ton code

Farpaitement

T'as un environnement kylix qui tourne sur ta machine?

On va recommencer avec des questions simples, la solution en sortira j'en suis sûr

Déjà, pourquoi un process passe en "Stopped"?

Parce qu'il reçoit le signal SIGSTOP

Edith: ou le signal SIGTSTP, avec un CTRL-Z dans une console...

Que fait ton process à la fin de la requête ?
Le lien lighttpd-fastcgi est via un socket TCP ? Un socket Unix ? Un pipe ?
Si tu le fais via un socket TCP, tu peux mettre ethereal wireshark pour sniffer ce qui passe ?