Bug 476415

Summary: set TCP connection socket SO_KEEPALIVE option to prevent from dead session waiting forever
Product: [Fedora] Fedora Reporter: maksym <verem>
Component: libxcbAssignee: Adam Jackson <ajax>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 10CC: ajax, mnowak
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: 1.1.91-8.fc10 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-12-04 23:57:22 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
set SO_KEEPALIVE flag on socket none

Description maksym 2008-12-14 13:15:05 UTC
I am deploying LTSP5 against Fedora Core 10.

The problem i have is if terminal (thin X11 client) dies or halt or poweroff, application started on a server remains running and listen their socket for requests from terminal, for example after two terminal poweroff i have a some process waiting:

[root@elbrus screen.d]# date; netstat -apn | grep 10.1.5.153 | sort -k 4
субота, 13 грудня 2008 18:42:25 +0200
tcp        0      0 10.1.1.4:42693              10.1.5.153:6001             ESTABLISHED 31318/gdm-simple-sl 
tcp       64      0 10.1.1.4:42696              10.1.5.153:6001             ESTABLISHED 31339/dbus-launch   
tcp        0      0 10.1.1.4:42697              10.1.5.153:6001             ESTABLISHED 31339/dbus-launch   
tcp        0      0 10.1.1.4:42698              10.1.5.153:6001             ESTABLISHED 31341/gnome-session 
tcp        0      0 10.1.1.4:42700              10.1.5.153:6001             ESTABLISHED 31349/metacity      
tcp        0      0 10.1.1.4:42702              10.1.5.153:6001             ESTABLISHED 31355/plymouth-log- 
tcp        0      0 10.1.1.4:514                10.1.5.153:53188            ESTABLISHED 29067/rsyslogd      
tcp        0      0 10.1.1.4:514                10.1.5.153:53399            ESTABLISHED 29067/rsyslogd      
tcp        0      0 10.1.1.4:59272              10.1.5.153:6001             TIME_WAIT   -                   
tcp        0      0 10.1.1.4:60119              10.1.5.153:6001             ESTABLISHED 32728/gdm-simple-sl 
tcp       64      0 10.1.1.4:60122              10.1.5.153:6001             ESTABLISHED 32749/dbus-launch   
tcp        0      0 10.1.1.4:60123              10.1.5.153:6001             ESTABLISHED 32749/dbus-launch   
tcp        0      0 10.1.1.4:60124              10.1.5.153:6001             ESTABLISHED 32751/gnome-session 
tcp        0      0 10.1.1.4:60126              10.1.5.153:6001             ESTABLISHED 32758/gnome-setting 
tcp        0      0 10.1.1.4:60127              10.1.5.153:6001             ESTABLISHED 32759/metacity      
tcp        0      0 10.1.1.4:60129              10.1.5.153:6001             ESTABLISHED 32765/plymouth-log- 
tcp        0      0 10.1.1.4:60130              10.1.5.153:6001             ESTABLISHED 32764/gdm-simple-gr 
tcp        0      0 10.1.1.4:9572               10.1.5.153:33675            ESTABLISHED 32702/sh            
[root@elbrus screen.d]#

and their remains in running state and opened sockets till server reboot.

After some days of working i have a bunch of process waiting for reply from dead Display sessions.

As solution i did a patch that set *SO_KEEPALIVE* on opened socket.

As result, applications dies gracefully in a predictable interval, so setting sysctl variables:
net.ipv4.tcp_keepalive_time = 60
net.ipv4.tcp_keepalive_probes = 6
net.ipv4.tcp_keepalive_intvl = 10
net.ipv4.tcp_fin_timeout = 10
could help to decrease time their waiting for connection been closed.

Patch attached.

Comment 1 maksym 2008-12-14 13:17:21 UTC
Created attachment 326870 [details]
set SO_KEEPALIVE flag on socket

Comment 2 Michal Nowak 2009-08-24 10:55:46 UTC
maksym: Did you try to send the patch upstream? That's usually the best way how to have it downstream (Fedora).

Comment 3 maksym 2009-08-25 06:44:03 UTC
(In reply to comment #2)
> maksym: Did you try to send the patch upstream?
no. should i?

> That's usually the best way how
> to have it downstream (Fedora).  
Is it possible to move this post to suitable category?
Any chance for this patch to be commited?

Comment 4 Michal Nowak 2009-08-25 08:29:37 UTC
(In reply to comment #3)
> (In reply to comment #2)
> > maksym: Did you try to send the patch upstream?
> no. should i?

Well, when is the patch applied upstream, we will have it in fedora with the next upstream release of libxcb.

> 
> > That's usually the best way how
> > to have it downstream (Fedora).  
> Is it possible to move this post to suitable category?

Not sure what you mean...?

> Any chance for this patch to be commited?  

Well, the load of bugs is higher than package maintainer can make, so, he prioritize his work and thus some bugs are still open after several months. When you send the patch upstream, you probably will have the fastest reaction possible.

Comment 5 Bug Zapper 2009-11-18 10:28:06 UTC
This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '10'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 10's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 10 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 6 Fedora Update System 2009-12-02 19:50:14 UTC
libxcb-1.1.91-8.fc10 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/libxcb-1.1.91-8.fc10

Comment 7 Fedora Update System 2009-12-04 23:57:16 UTC
libxcb-1.1.91-8.fc10 has been pushed to the Fedora 10 stable repository.  If problems still persist, please make note of it in this bug report.