2009-10-19 5 views
1

J'ai une application serveur qui écrit dans un thread séparé un descripteur de fichier popen ("myCommand", "w") et si la commande passée à popen() renvoie une sortie vers stdout ou stderr, l'application my se termine. Cependant, ce n'est qu'un problème lorsque mon application serveur a été invoquée via inetd, si j'ai utilisé ssh pour lancer le serveur, il n'y a pas ce problème. De même, lorsque mon application serveur lit un descripteur de fichier popen ("myCommand2", "r") dans un thread séparé et si la commande passée à popen() donne une sortie à stderr (stdin va à mon pipe), l'application se termine. Encore une fois, cela se produit uniquement avec l'invocation inetd, pas avec l'invocation ssh.Pourquoi write() exécute-t-il un programme d'exit lorsque le tube écrit sur stdout?

+0

Inetd fonctionne en redirigeant les E/S standard du serveur lancé. C'est possible que tu manges ça. Il serait utile si vous pouviez spécifier comment votre serveur «sort». Est-ce que ça plante? Laissez un code de sortie? – Duck

+0

Je ne sais pas comment cela se termine, cela fait partie du problème. Je vois que les destructeurs sont exécutés cependant. Je suis incapable de joindre via gdb, donc je ne sais pas ce qui échoue. Je reçois également aucun message d'erreur qui est visible pour moi. Je sais via printfs inséré dans le code que l'appel à write() ou read() est là où il échoue. – WilliamKF

Répondre

0

vous devez fermer tous les fds existants du processus avant d'ouvrir le tube, puis effectuez une redirection d'E/S. C'est parce que si inetd, le processus s'exécute comme un démon.

+0

Pourriez-vous élaborer s'il vous plaît? Le serveur invoqué via inetd plante quand il lit ou écrit sur le tuyau fourni par popen quand ce tuyau écrit dans stderr qui n'a pas été redirigé dans l'appel à popen. – WilliamKF

+0

Veuillez d'abord vous assurer que vous avez ajouté le nom de chemin d'accès complet à la commande appelée, par ex. par popen ("myCommand", "w"), vous écririez popen ("/ home/myCommand", ...), sinon popen() échouerait donc toute lecture/écriture du tube provoquerait segault etc, sauf si votre La commande appelée est dans le PATH. si ce n'est pas le cas, appelez daemon (0, 1) pour simuler inetd, avant d'appeler daemon(), vous devriez appeler setsid() et filtrer SIGINT, SIGHUP, SIGQUIT, SIGPIPE, SIGTTIN, SIGTTOU et SIGTERM. après la simulation, vous pouvez trouver la cause. – Test

+0

utilise dup2() si faire la redirection. – Test

Questions connexes