How to get atexit hooks to run in the presence of execv?

[R. Bernstein]

Mark Wooding <mdw at distorted.org.uk> writes:

> rocky at panix.com (R. Bernstein) writes:
>
>> Recently, I added remote debugging via TCP sockets. (Well, also FIFO's
>> as well but closing sockets before restarting is what's of concern.)
>>
>> I noticed that execv in Python 2.5.2 doesn't arrange exit hooks to get
>> called. Should it?
>
> I'd consider that to be highly unusual.  Certainly, the C atexit(3)
> function is called only in response to a call to exit(3) (possibly
> implicitly by returning from main), and not by execve(2) or any of its
> little friends.
>
> Your specific problem is to do with file descriptors, so it's probably
> best dealt with using the close-on-exec flag:
>
>         from fcntl import fcntl, F_GETFD, F_SETFD, F_CLOEXEC
>
>         sk = socket(...)
>         ## ...
>         fcntl(sk.fileno(), F_SETFD,
>               fcntl(sk.fileno(), F_GETFD) | FD_CLOEXEC)
>
> Now the socket will be magically closed when you exec.. another program.

Thanks for the wealth of information. Alas, somehow I think this begs
the question. I *know* how to arrange in the debugger for it to clean
up after itself. But it's the program being debugged which I have no
control over. And I would like to give it an opportunity to clean up
after itself. 

>
> Finally, can I urge against TCP sockets in an application like this?

By all means, I hope people will offer thoughts, concerns and ideas. 

> Certainly without adequate authentication, it will simply be insecure
> even within a single multiuser host (e.g., using localhost only) -- and
> assuming that even a home machine has only a single user is becoming
> less realistic.  Unix-domain sockets live in the filesystem, and access
> to them is limited using the standard filesystem mechanisms.
>
> If you're expecting inter-host communications (e.g., remote debugging),
> it's a good idea to protect the session using TLS or something (much as
> I dislike the TLS certification/public-key- distribution model it's way
> better than nothing at all).

Well, I also started coding FIFO's as well as TCP sockets, partly
because I could, and partly to try to try to keep the interface
generic. And in the back of my mind, I'd like to add serial devices as
well - I don't see a reason not to.

Initially, I probably won't add authentication or encryption. I'm
having enough of a time trying to get this much working. (cpickling
over sockets seems to still require knowing how many messages were
sent and unpickling each of those, and TCP_NODELAY isn't allowed and
doesn't seem the right thing either.)

However what I really would like to see is authentication and
encription added as an independent plugin layer much as I view whether
one is debugging locally or not. So I don't see this as an issue per
se with TCP sockets.

>
> -- [mdw]