launchpad-dev team mailing list archive

[John Arbash Meinel <john@xxxxxxxxxxxxxxxxx>]

-----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-----