Bug 12301

Summary: gdm 2.0beta2 appears to leak file descriptors
Product: [Retired] Red Hat Linux Reporter: p.jenner
Component: gdmAssignee: Havoc Pennington <hp>
Status: CLOSED RAWHIDE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 6.2   
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2000-06-19 08:14:45 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:

Description p.jenner 2000-06-15 14:44:39 UTC
gdm 2.0beta2 (installed first as the Red Hat 6.2 shipped package and then
upgraded to gdm-2.0beta2-26 from the package on the Red Hat 6.2 errata
mirrors) appears to be leaking file descriptors.

The first sign was when the server ran out of file handles and the kernel
reported via dmesg: "VFS: file-max limit 4096 reached".  At the time no
unusual processes were being run, just five standard GNOME login sessions
via XDM from X-terminals and PCs running Exceed.

I increased the file descriptors using /proc/sys/fs/file-max to solve the
immediate problem and then used lsof to track down the user of the files. 
This appeared to be gdm:

[root@molniya /root]# lsof | grep gdm | wc -l
   1856

In other words, the combined gdm and gdmlogin (matches 'grep gdm')
processes had over 1800 files open between them.  Looking more closely at
the master gdm and the files it held with lsof, I noticed that it was
holding multiple file descriptors for the gdm log files.

[root@molniya /root]# lsof -p 3230 | grep '/var/gdm/' | sort +8 | less
<snip>
gdm     3230 root   50w   REG        8,7       0   26142
/var/gdm/sscpc067.ee.surrey.ac.uk:0.log
gdm     3230 root   51w   REG        8,7       0   26142
/var/gdm/sscpc067.ee.surrey.ac.uk:0.log
gdm     3230 root   52w   REG        8,7       0   26142
/var/gdm/sscpc067.ee.surrey.ac.uk:0.log
gdm     3230 root   56w   REG        8,7       0   26142
/var/gdm/sscpc067.ee.surrey.ac.uk:0.log
gdm     3230 root   58w   REG        8,7       0   26142
/var/gdm/sscpc067.ee.surrey.ac.uk:0.log
gdm     3230 root   61w   REG        8,7       0   26142
/var/gdm/sscpc067.ee.surrey.ac.uk:0.log
gdm     3230 root   69w   REG        8,7       0   26142
/var/gdm/sscpc067.ee.surrey.ac.uk:0.log
gdm     3230 root   73w   REG        8,7       0   26142
/var/gdm/sscpc067.ee.surrey.ac.uk:0.log
gdm     3230 root   77w   REG        8,7       0   26142
/var/gdm/sscpc067.ee.surrey.ac.uk:0.log
gdm     3230 root   79w   REG        8,7       0   26142
/var/gdm/sscpc067.ee.surrey.ac.uk:0.log
gdm     3230 root   83w   REG        8,7       0   26142
/var/gdm/sscpc067.ee.surrey.ac.uk:0.log
<snip>

This is a part of the output but it is replicated for other displays.  It
seems to show that the master gdm process holds multiple file descriptors
open for the same log file and does this for every display.  Other gdm
child processes appear to do the same thing.  The combined effect of this
possible file descriptor leak is that the kernel runs out of file
descriptors quickly.

I have yet to look at the latest gdm 2.0beta4 to see if the same problem is
present or to check the source to see what is happening.  However it seemed
worth reporting to you as others may be seeing the same problem.

Comment 1 p.jenner 2000-06-19 08:14:43 UTC
I have had a look at the source of gdm 2.0beta4.  There is nothing in the
changelog to show this has been noted or fixed.  Looking in the source in file
daemon/xdmcp.c, the log file is opened on line 773 with handle 'logfd'.  However
it does not look like the log file is closed again at any point, at least there
is no obvious close call on logfd.

Comment 2 Havoc Pennington 2000-06-19 20:39:37 UTC
I've added a close(logfd) in the latest version, should solve the problem.

Comment 3 Havoc Pennington 2001-01-02 19:48:15 UTC
*** Bug 22794 has been marked as a duplicate of this bug. ***