Bug 50580 - Only one KDE session per machine??
Only one KDE session per machine??
Product: Red Hat Linux
Classification: Retired
Component: fam (Show other bugs)
i386 Linux
high Severity high
: ---
: ---
Assigned To: Alexander Larsson
Aaron Brown
: 50212 51319 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2001-08-01 08:52 EDT by Tim Waugh
Modified: 2005-10-31 17:00 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-08-07 12:06:37 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Tim Waugh 2001-08-01 08:52:44 EDT
Description of Problem:
I can only run one KDE session at once on this multi-user machine.

How Reproducible:

Steps to Reproduce:
1. Due to another bug, I am using gdm instead of kdm, since kdm doesn't
manage remote displays at all.  Set up gdm so that xdmcp is allowed.  Go to
runlevel 5.
2. On another machine, 'X -query roswell' to get a login window.
3. Log in on both machines, one after the other, with KDE sessions
(different non-root users).

Actual Results:
The 'initialising system services' checkpoint is never passed, and
eventually the KDE splashscreen goes away, and that's it.

Expected Results:
Both sessions start up normally.

Additional Information:
If I close the successfully session and try again on the failed one, it works.

This is a major regression!
Comment 1 Bernhard Rosenkraenzer 2001-08-01 09:30:56 EDT
Does it work if you remove the various "rm /tmp/foo" commands from 
Comment 2 Tim Waugh 2001-08-01 09:40:06 EDT
After I put 'alias rm=:' at the top, yes, I could log in a second time.
Comment 3 Tim Waugh 2001-08-01 14:03:07 EDT
..but I think that must have been chance.  I tried again, with a similar
situation (two signal-blocked kdeinit processes from another user lying around)
and couldn't log in.  I had to killall -9 kdeinit first, and then I could log in
file, with the original unmodified /usr/bin/startkde.

However, when I did log in that time, kicker didn't appear.  I logged out and
back in again, and it did.
Comment 4 Glen Foster 2001-08-01 16:30:09 EDT
This defect is considered MUST-FIX for Fairfax
Comment 5 Bernhard Rosenkraenzer 2001-08-06 09:09:23 EDT
untested fix in 2.2-1
Comment 6 Tim Waugh 2001-08-06 14:40:07 EDT
Tested; didn't work.
Comment 7 Tim Waugh 2001-08-07 06:36:20 EDT
It's sgi_fam related.  'chkconfig sgi_fam off; service xinetd restart' has 
made the problem go away for now.

I also tried this: enable sgi_fam, start xinetd, log in on display 1, log in 
as a different user on display 2, it locks.  Stop xinetd, it carries on again.

Comment 8 Bernhard Rosenkraenzer 2001-08-07 09:12:36 EDT
This is a fam problem - the same is true for anything else using fam (e.g. 

Let me know if you can't fix this in time for the 7.2 release; in that case 
I'll recompile kdelibs without fam support.
Comment 9 Tim Waugh 2001-08-07 12:06:31 EDT
A more detailed how-to-reproduce than the one earlier in this report:

1. chkconfig sgi_fam on; service xinetd restart
2. useradd jim; useradd joe
3. As user jim: switchdesk KDE
4. As user joe: switchdesk KDE
5. Go to runlevel 3
6. As user jim: startx -- :0
7. Wait for session to start.
8. As user joe: startx -- :1
9. Wait for session to start. (It won't.)
Comment 10 Alexander Larsson 2001-08-08 10:55:14 EDT
Ok. Stupid bug in famd. Upgrading to fam-2.6.4-9 should fix this.

Comment 11 Bernhard Rosenkraenzer 2001-08-09 16:48:03 EDT
*** Bug 51319 has been marked as a duplicate of this bug. ***
Comment 12 Alexander Larsson 2001-08-10 11:37:39 EDT
*** Bug 50212 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.