This service will be undergoing maintenance at 20:00 UTC, 2017-04-03. It is expected to last about 30 minutes
Bug 248775 - DBus session bus autostart script fails to close open file handles
DBus session bus autostart script fails to close open file handles
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: dbus (Show other bugs)
5.0
All Linux
high Severity high
: ---
: ---
Assigned To: Matthias Clasen
desktop-bugs@redhat.com
:
Depends On: 248771
Blocks:
  Show dependency treegraph
 
Reported: 2007-07-18 13:58 EDT by Daniel Berrange
Modified: 2014-03-07 08:45 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-03-07 08:45:56 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Daniel Berrange 2007-07-18 13:58:17 EDT
+++ This bug was initially created as a clone of Bug #248771 +++

Description of problem:
If you have an application which tries to connect to the session bus, but there
is no bus running, the DBus libraries will try to automatically start one. This
appears to be done by spawning dbus-launch. Unfortunately the code does not
appear to close all open file handles after fork()'ing.  So the DBus daemon
inherits all open file handles from the application.

This results in all sorts of very serious badness depending on what the parent
app had open. eg, one app I've hit this with has a number of files open, but
deleted - the intention being that when the app exits all the files are cleaned
up. THis never happens because the auto-spawned daemon keeps the files open. 
The current problem is hitting virt-manager - it has a VNC connection open to a
Xen guest - the DBus daemon inherits this socket file handle so blocks *anyone*
else ever connecting to that guest again.


Version-Release number of selected component (if applicable):
dbus-1.0.2-6.fc7

How reproducible:
Always

Steps to Reproduce:
1. ssh root@some-remote-host
2. Make sure no dbus session bus is running
3. # cat > dbus-demo.py <<EOF
#!/usr/bin/python

log  = open("/tmp/demo.log", "w")

import dbus
import dbus.glib

bus = dbus.SessionBus()
EOF

4. DBUSPID=`ps auxwf | grep dbus-daemon | grep session | awk '{print $2}'`
4.  lsof -p $DBUSPID
  
Actual results:
The dbus daemon has '/tmp/demo.log'  open

Expected results:
The dbus daemon has *no* files open from the parent process.

Additional info:
After forking, the code which autolaunchs the daemon needs to

      open_max = sysconf (_SC_OPEN_MAX);
      for (i = 0; i < open_max; i++)
          close(i);

And then re-open  stdin, stdout & stderr to use  /dev/null.
Comment 1 RHEL Product and Program Management 2012-09-18 13:40:31 EDT
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unable to address this
request at this time.

Red Hat invites you to ask your support representative to
propose this request, if appropriate, in the next release of
Red Hat Enterprise Linux.
Comment 3 RHEL Product and Program Management 2014-03-07 08:38:27 EST
This bug/component is not included in scope for RHEL-5.11.0 which is the last RHEL5 minor release. This Bugzilla will soon be CLOSED as WONTFIX (at the end of RHEL5.11 development phase (Apr 22, 2014)). Please contact your account manager or support representative in case you need to escalate this bug.

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