You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Dean Gaudet <dg...@arctic.org> on 1997/07/23 19:39:04 UTC

solaris HUP blues

Why don't we just keep sockets open across a HUP like we do for graceful? 
It would solve both of the solaris HUP problems... and avoid us having to
figure out why the HUP problem is solved on my test server with the patch,
but not on the two users of PR#888 and PR#896.

Can anyone see any problems with this? 

Dean



Re: solaris HUP blues

Posted by Dean Gaudet <dg...@arctic.org>.
We could really hack around SOLARIS2 < 260 by doing:

- open log files
- open LOW_SLACK_LINE copies of /dev/null
- open sockets
- close the /dev/null crud

Or we could just make it NO_SLACK and say "tough... if you can do without
SIGHUP then edit conf.h and undef NO_SLACK". 

We could beg your Sun contact for the necessary streams code to "properly" 
do the dup ;) 

Remember that we can just reorder operations on SOLARIS2 < 260 and leave
everyone else with the current order, which seems to be working fine.  If
you've found an order that works, I'm game for this. 

Dean

On Thu, 24 Jul 1997, Marc Slemko wrote:

> On Wed, 23 Jul 1997, Dean Gaudet wrote:
> 
> > Oh my gawd, we use SO_REUSEADDR?  For some reason I've never noticed that. 
> > This of course means that if a site tries to run a server on a port >=
> > 1024 that any old user can share the port with the server.  Not that
> > there's not other problems with high-numbered ports ... but just an
> > observation. 
> 
> Yup.  More like steal on most setups, since Apache is bound to INADDR_ANY.
> Some systems, like OpenBSD and Linux (? ... there have been so many broken
> implementions of this restriction on Linux that I'm not sure where the
> current score is...) do things like have a user credential associated with
> a socket and don't let other users bind to it.
> 
> I won't bring up pserver again right now.  Sigh.
> 
> > 
> > So you think the slack should just be moved after all the option settings? 
> > Somehow I figured that'd be more dangerous.
> 
> Sigh.  I think we should say any version of Solaris before 2.6 is
> unsupported.  Sigh.  
> 
> We can't have the option settings before ap_slack, because they may
> magically disappear on some systems when you do the dup().  We can't have
> ap_slack before the bind on Solaris, because that is broken.  We can't
> have the options after the bind, because then the bind may fail.
> 
> Can anyone verify my fear of systems loosing settings when you do a dup()?
> Ah.  Ok, on Solaris we can do them before the bind and ap_slack,
> everywhere else we do them before the bind and after ap_slack.  That is
> assuming Solaris doesn't loose socket options on a dup().  
> 
> And no, keeping the sockets open across HUPs doesn't solve the
> SO_REUSEADDR problem.
> 
> 


Re: solaris HUP blues

Posted by Marc Slemko <ma...@worldgate.com>.
On Wed, 23 Jul 1997, Dean Gaudet wrote:

> Oh my gawd, we use SO_REUSEADDR?  For some reason I've never noticed that. 
> This of course means that if a site tries to run a server on a port >=
> 1024 that any old user can share the port with the server.  Not that
> there's not other problems with high-numbered ports ... but just an
> observation. 

Yup.  More like steal on most setups, since Apache is bound to INADDR_ANY.
Some systems, like OpenBSD and Linux (? ... there have been so many broken
implementions of this restriction on Linux that I'm not sure where the
current score is...) do things like have a user credential associated with
a socket and don't let other users bind to it.

I won't bring up pserver again right now.  Sigh.

> 
> So you think the slack should just be moved after all the option settings? 
> Somehow I figured that'd be more dangerous.

Sigh.  I think we should say any version of Solaris before 2.6 is
unsupported.  Sigh.  

We can't have the option settings before ap_slack, because they may
magically disappear on some systems when you do the dup().  We can't have
ap_slack before the bind on Solaris, because that is broken.  We can't
have the options after the bind, because then the bind may fail.

Can anyone verify my fear of systems loosing settings when you do a dup()?
Ah.  Ok, on Solaris we can do them before the bind and ap_slack,
everywhere else we do them before the bind and after ap_slack.  That is
assuming Solaris doesn't loose socket options on a dup().  

And no, keeping the sockets open across HUPs doesn't solve the
SO_REUSEADDR problem.


Re: solaris HUP blues

Posted by Dean Gaudet <dg...@arctic.org>.
Oh my gawd, we use SO_REUSEADDR?  For some reason I've never noticed that. 
This of course means that if a site tries to run a server on a port >=
1024 that any old user can share the port with the server.  Not that
there's not other problems with high-numbered ports ... but just an
observation. 

So you think the slack should just be moved after all the option settings? 
Somehow I figured that'd be more dangerous.

Dean

On Wed, 23 Jul 1997, Marc Slemko wrote:

> The current problem with Solaris is probably that you moved the
> SO_REUSEADDR after the bind.
> 
> If I start a server, make a connection, kill the server and try to restart
> it, it whines when SO_REUSEADDR isn't set first.  This may or may not be
> what others are seeing.
> 
> On Wed, 23 Jul 1997, Dean Gaudet wrote:
> 
> > Why don't we just keep sockets open across a HUP like we do for graceful? 
> > It would solve both of the solaris HUP problems... and avoid us having to
> > figure out why the HUP problem is solved on my test server with the patch,
> > but not on the two users of PR#888 and PR#896.
> > 
> > Can anyone see any problems with this? 
> > 
> > Dean
> > 
> > 
> 
> 


Re: solaris HUP blues

Posted by Marc Slemko <ma...@worldgate.com>.
The current problem with Solaris is probably that you moved the
SO_REUSEADDR after the bind.

If I start a server, make a connection, kill the server and try to restart
it, it whines when SO_REUSEADDR isn't set first.  This may or may not be
what others are seeing.

On Wed, 23 Jul 1997, Dean Gaudet wrote:

> Why don't we just keep sockets open across a HUP like we do for graceful? 
> It would solve both of the solaris HUP problems... and avoid us having to
> figure out why the HUP problem is solved on my test server with the patch,
> but not on the two users of PR#888 and PR#896.
> 
> Can anyone see any problems with this? 
> 
> Dean
> 
> 


Re: solaris HUP blues

Posted by Marc Slemko <ma...@worldgate.com>.
I am installing Solaris x86 across the room right now, so I will try it
there and on a couple of other machines.  The problem with keeping sockets
open is that it means any problems that have popped up (accept() failed,
anyone?) won't be fixed by a HUP.

On Wed, 23 Jul 1997, Dean Gaudet wrote:

> Why don't we just keep sockets open across a HUP like we do for graceful? 
> It would solve both of the solaris HUP problems... and avoid us having to
> figure out why the HUP problem is solved on my test server with the patch,
> but not on the two users of PR#888 and PR#896.
> 
> Can anyone see any problems with this? 
> 
> Dean
> 
>