Bug 12301 - gdm 2.0beta2 appears to leak file descriptors
Summary: gdm 2.0beta2 appears to leak file descriptors
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: gdm   
(Show other bugs)
Version: 6.2
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Havoc Pennington
QA Contact:
: 22794 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2000-06-15 14:44 UTC by p.jenner
Modified: 2008-05-01 15:37 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2000-06-19 08:14:45 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

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

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
gdm     3230 root   50w   REG        8,7       0   26142
gdm     3230 root   51w   REG        8,7       0   26142
gdm     3230 root   52w   REG        8,7       0   26142
gdm     3230 root   56w   REG        8,7       0   26142
gdm     3230 root   58w   REG        8,7       0   26142
gdm     3230 root   61w   REG        8,7       0   26142
gdm     3230 root   69w   REG        8,7       0   26142
gdm     3230 root   73w   REG        8,7       0   26142
gdm     3230 root   77w   REG        8,7       0   26142
gdm     3230 root   79w   REG        8,7       0   26142
gdm     3230 root   83w   REG        8,7       0   26142

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. ***

Note You need to log in before you can comment on or make changes to this bug.