On Fri, Aug 28, 2009 at 11:12:37PM +0100, Andrew Gabriel wrote: > Liane Praza wrote: > >I'm filing this case for Gary as closed-approved-automatic, as it seems > >an obvious extension to existing interface. As usual, speak up if you'd > >like to see it promoted to a fasttrack. > > > >tcp_keepalive For inetd Services > >Gary Mills > >08/27/2009 > > > >1. Summary > > > >The inetd restarter defines a set of properties to control the behaviour > >of the services it manages. This case adds the option `tcp_keepalive' > >to the inetd restarter. Setting this option enables the TCP keepalive > >facility for connections to services managed by inetd. It's needed > >because some services do not have the ability to enable this facility by > >themselves. > > This is quite different from any of the existing inetd configuration > parameters - inetd doesn't currently allow manipulation of socket > configuration parameters. > Please can you describe a case where this is intended to be used? (I > ask, because mostly whenever I do see it being used, the author > misunderstood what it does and shouldn't have been using it.) > Why do you intend to allow access to this socket parameter, but no > others (such as SO_SNDBUF, SO_RCVBUF, etc)?
We've been using the keepalive option for some time, both on Solaris 9 and Solaris 10, through a wrapper, only for telnet and rlogin. That's because we have a firewall that disconnects idle sessions after one hour. This works without complaints for HTTP connections but is extremely annoying for the few terminal connections that exist. The telnet and rlogin servers have no way to enable keepalives at any level. Yes, you can say that doing that is a misuse of the facility, although I'd prefer to call it a clever use. Bug 6263835, initiated by me, suggests adding the option to inetd so that the wrapper would no longer be necessary. My webrev is at: http://cr.opensolaris.org/~jgmills/ws-6263835/ Yes, there are many other TCP options that inetd could set. In fact, I expected that to be one of the objections. I didn't think that we wanted to make all of them available in the inetd configuration, unless we had some justification for doing that. In fact, there are so many of them that we'd have to devise a language for them, rather than adding all of them as separate options to inetd. I didn't want to open that can of worms. -- -Gary Mills- -Unix Group- -Computer and Network Services-
