If this isn't exactly what you wanted, please try our Search (there's a LOT of techy and non-techy stuff here about Linux, Unix, Mac OS X and just computers in general!):
See also Keep in touch (tcp keepalives etc.)
From: Bela Lubkin <belal@sco.com> Subject: Re: Failure to Log Off Users on OSR5.0.7 Date: Fri, 16 Jan 2004 16:40:37 GMT Message-ID: <20040116164037.GE24746@sco.com> References: <Pine.SC5.4.10.10401160948310.13943-100000@ris.UniXpress.com> Lucky Leavell wrote: > OS: OSR5.0.7 with MP1/UP1 installed > > I have a customer who reports that OSR5.0.7 fails to log off users whose > telnet session is terminated by a power failure on the client side. (I.e., > who still shows them logged on.) This problem did not occur on earlier > versions of OSR5.
A machine which is going down in a power failure does not send out "I'm dying now" messages. It is normal for sessions from a rebooted machine to stay alive for a while. Once the client is finished rebooting, next time the server sends it anything on the telnet session, it will get a TCP "reset" packet (meaning "What are you talking about? I don't have a session open with you on that socket number!") If the users are running an application that chatters (e.g. updates an on-screen time of day once a minute), the sessions will disappear pretty quickly. If not, they'll stay around until a TCP "keepalive" packet is sent. The default values of the keepalive kernel parameters will keep such sessions alive for over 2 hours. See the sections on keepalives in telnetd(ADMN), tcp(ADMP). > Has anyone else experienced this? > > Solutions? (Other than a script to manually kill the telnet sessions on the > OSR5.0.7 side) Tuning the keepalive parameters sharply down may help. You can do it systemwide with the parameters described in tcp(ADMP); or for telnet sessions only, by adding command line flags to the telnetd invocation in /etc/inetd.conf. If you see a big difference from "earlier versions of OSR5", it must be that they had done such tuning on the earlier releases. The down side of tightening the keepalive parameters is that you also sharply limit TCP's resilience in the face of cable outages. A session whose both ends are alive and ready to run normally stays alive even if an intermediate cable or router is disconnected for a few minutes. If you've told the server to frantically send keepalives, it will notice a cable break and disconnect sessions that would otherwise have survived nicely. >Bela<
/Bofcusm/2426.html copyright 1997-2004 (various authors) All Rights Reserved
Have you tried Searching this site?
Unix/Linux/Mac OS X support by phone, email or on-site: Support Rates
This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more. We appreciate comments and article submissions.
Many of the products and books I review are things I purchased for my own use. Some were given to me specifically for the purpose of reviewing them. I resell or can earn commissions from the sale of some of these items. Links within these pages may be affiliate links that pay me for referring you to them. That's mostly insignificant amounts of money; whenever it is not I have made my relationship plain. I also may own stock in companies mentioned here. If you have any question, please do feel free to contact me.
Specific links that take you to pages that allow you to purchase the item I reviewed are very likely to pay me a commission. Many of the books I review were given to me by the publishers specifically for the purpose of writing a review. These gifts and referral fees do not affect my opinions; I often give bad reviews anyway.
We use Google third-party advertising companies to serve ads when you visit our website. These companies may use information (not including your name, address, email address, or telephone number) about your visits to this and other websites in order to provide advertisements about goods and services of interest to you. If you would like more information about this practice and to know your choices about not having this information used by these companies, click here.
Click here to add your comments
Don't miss responses! Subscribe to Comments by RSS or by Email
Click here to add your comments
If you want a picture to show with your comment, go get a Gravatar