[stunnel-users] stunnel automatically listening to extra ports:BAD

Fri Jan 11 23:41:55 CET 2008

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