-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
... >> >> Which is also weird because 'cat /.../fifo' finishes correctly. >> >> Anyway, ideally I wouldn't need the proxy in the middle, and just have >> that done in the twisted code. >> >> I'm still a little concerned about detecting process lifetimes and exit >> codes (if they matter to twisted), since this process isn't a direct >> child. Should I be trying to convey that information via another channel? > > I'm not sure, why would it matter? It might matter because > > 1- we want to log the exit code to make sure errors don't go undetected > 2- we want to make sure the ssh socket is closed (but presumably that > will just happen through the socket closing) > > I think I understand the process model you're using but what do you > mean by " this process isn't a direct child"? > launchpad codehosting is a twisted daemon (I don't know exactly how it gets started). Somehow we will also start the 'lp-service' daemon. Either from the Conch ssh daemon, or via the 'make run' sort of scripts. Once running, the ssh daemon will make a request to the lp-service for it to fork itself, and reply with a message about where to find the named pipes that the new process will communicate. (As opposed to just using stdin/stderr/stdout of a Popen() process.) The way it is written, the lp-service daemon periodically polls its forked children to clean up any zombies, etc. It will also delete any named pipes that are still on the filesystem in case a child process dies without cleaning itself up. (If you request a fork, but never connect, that child hangs indefinitely trying to open the pipe. Potentially we want to send SIGINT, or something to the children.) Anyway, *if* we start lp-service from Conch, then the per-request processes would be grand-children of Conch. (But I don't think 'os.wait' will notice them.) If we start the service as a normal daemon, it would end up as a child of 'init' most likely, and then there would certainly be no direct relationship between the per-request processes, and the Conch daemon. I don't know that it matters. Presumably a client that connects will send information to the 'stdin' pipe, until the client is done. It may hold open the connection for a while, but eventually the client process will exit, and the connection will close, thus closing the stdin for the new connection, and presumably that will cause the lp-serve --inet to decide it is done and exit. John =:-> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxrMhsACgkQJdeBCYSNAAMQcwCfXhhTe819xB6eMlbm8hEhLoie looAoJL9BRRXadUyg0owIKy+a43E5eyX =lNGY -----END PGP SIGNATURE----- _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
