Alan,
On Fri, 11 Jan 2008, Alan Pinstein wrote: [...]
Yes. RHEL5.
The following is an educated guess:
Open connections are open file descriptors, and fork()/exec() do not close open file descriptors. Thus, stunnel is inheriting the open connection. And, since it knows nothing about it, it does not close it or anything like that. So it's not that it activelly listens on it, but only that it does not bother to stop. You might check this theory by trying to connect to the port *after* apache is shut down. If I'm right you should get no answer at all.
I don't know a lot about sockets programming, but I am not sure this makes sense... I don't WANT stunnel to stop listening to those ports; rather it shouldn't ever start. stunnel has a config file, so I'd expect it to only listen to the ports it was told to listen to, which is 4449.
I run lots of child processes from php and none of them end up listening to port 80/443 once the server exits.
Although, now that I think about it, I am not sure I daemonize any processes from a php script...
But still I think that stunnel is actively listening on these ports. Forked processed just don't inherit sockets from parents AFAIK....
Not so.
So, the solution is to have the file descriptors close when exec'ing stunnel. PHP or apache might have some option somewhere to do that (look for "close on exec" or something similarly named), but if not, you might have to write some sort of wrapper to do it. It's a messy thing, because AFAIK there's no clean way to do it short of
for (i = 0; i < [some-hopefuly-large-enough-value]; i++) close(i);
[...]
I've seen this problem discussed in other forums. It recently (re)surfaced in the Exim world. See, for example, the thread which starts at http://lists.exim.org/lurker/message/20080102.003418.fd1f8896.en.html and eventually leads to the rather more informative http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=366124 and http://bugs.php.net/bug.php?id=38915
The consensus seems to be that the problem lies with mod_php or maybe even Apache (though agreement is far from universal)
HTH, Richard