Bug 149162 - dbus sends SIGSTOP to startx process group when switching VTs [NEEDINFO]
Summary: dbus sends SIGSTOP to startx process group when switching VTs
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: dbus   
(Show other bugs)
Version: 5.0
Hardware: i386
OS: Linux
Target Milestone: ---
: ---
Assignee: Matthias Clasen
QA Contact: desktop-bugs@redhat.com
Depends On:
TreeView+ depends on / blocked
Reported: 2005-02-19 18:40 UTC by paul.knowles
Modified: 2014-06-02 13:17 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2014-06-02 13:17:14 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
pm-rhel: needinfo? (paul.knowles)

Attachments (Terms of Use)

Description paul.knowles 2005-02-19 18:40:14 UTC
Description of problem:

The dbus daemon/system seems to be sending a SIGSTOP to all the 
members of the startx process group when X registers the ctrl-alt-Fx
Vt switching commands.  When you switch back to the x session in
question, no SIGCONT is issued and hence everything is frozen.

Version-Release number of selected component (if applicable):

How reproducible: whenever dbus-launch is used to run .Xclients

Steps to Reproduce:
1. boot runlevel 3
2. login and run startx
3. ctrl-alt-F1 to switch to the console
4. ctrl-alt-Fx to switch back to the X session
5. play with the mouse since that's all that moves...
Actual results:  x session clients are frozen
Expected results: working x session clients

Additional info:
 The x session can be saved by issuing a SIGCONT to all paused
processes _except_ anything associated with dbus, i.e., from a working
VT: top -i -u $USERNAME, and for all lines with a T for the status,
issue SIGCONT, unless it is the dbus-launch process (leave it stopped)
Vt switch back the the x session Vt and things are working again.

in your primary .bashrc, define

# kill the DBUS lauch
export DBUS_SESSION_BUS_ADDRESS=some_garbage
export DBUS_LAUNCH=""

(see /etc/X11/xinit/xinitrc-common and /etc/X11/xinit/xinitrc
to understand how this saves you from the cluelessness of dbus)

At least in FC3, this dbus business has no documentation to explain
what is does or why it is needed.  It seems to be a new addition to
xorg.  Philosophically, it is very bad to stop a users processes just
because he or she has switched to another VT.

Comment 1 Mike A. Harris 2005-03-07 01:01:27 UTC
Sounds like a bug in dbus rather than xorg-x11.

Comment 2 Matthew Miller 2006-07-10 22:52:20 UTC
Fedora Core 3 is now maintained by the Fedora Legacy project for security
updates only. If this problem is a security issue, please reopen and
reassign to the Fedora Legacy product. If it is not a security issue and
hasn't been resolved in the current FC5 updates or in the FC6 test
release, reopen and change the version to match.

Thank you!

Comment 3 Victor Ashik 2007-03-31 17:39:38 UTC
It looks like the bug is resolved in FC6, but is not resolved in RHEL 5.
How to reproduce:

1. login as user in runlevel 3
2. exec startx
3. X Window system will hang soon

Please change product to RHEL5.

Comment 4 Matthew Miller 2007-03-31 19:20:22 UTC
Retested (see comment #3), so clearing the needinfo bit.

Comment 6 RHEL Product and Program Management 2014-03-07 13:42:40 UTC
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.

Comment 7 RHEL Product and Program Management 2014-06-02 13:17:14 UTC
Thank you for submitting this request for inclusion in Red Hat Enterprise Linux 5. We've carefully evaluated the request, but are unable to include it in RHEL5 stream. If the issue is critical for your business, please provide additional business justification through the appropriate support channels (https://access.redhat.com/site/support).

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