[stunnel-users] stunnel automatically listening to extra ports:BAD
Richard.Hall at ingenta.com
Fri Jan 11 23:41:55 CET 2008
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....
> > 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
and eventually leads to the rather more informative
The consensus seems to be that the problem lies with mod_php or maybe even
Apache (though agreement is far from universal)
More information about the stunnel-users