[You forgot to cc: the list]
Oops sorry thanks... my other lists do that automatically :)
All this is in a *nix, right?
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....
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);
Yeah that couldn't be a good idea...
I am open to using stunnel in a different way.
I suppose that I could just set it up in init.d to run on boot, but was hoping to not have to deal with another initd process for ease of management...
Thanks for any ideas.
Alan