Bug 50580 - Only one KDE session per machine??
Summary: Only one KDE session per machine??
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: fam
Version: 7.3
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Alexander Larsson
QA Contact: Aaron Brown
: 50212 51319 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2001-08-01 12:52 UTC by Tim Waugh
Modified: 2005-10-31 22:00 UTC (History)
1 user (show)

Clone Of:
Last Closed: 2001-08-07 16:06:37 UTC

Attachments (Terms of Use)

Description Tim Waugh 2001-08-01 12:52:44 UTC
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 13:30:56 UTC
Does it work if you remove the various "rm /tmp/foo" commands from 

Comment 2 Tim Waugh 2001-08-01 13:40:06 UTC
After I put 'alias rm=:' at the top, yes, I could log in a second time.

Comment 3 Tim Waugh 2001-08-01 18:03:07 UTC
..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 20:30:09 UTC
This defect is considered MUST-FIX for Fairfax

Comment 5 Bernhard Rosenkraenzer 2001-08-06 13:09:23 UTC
untested fix in 2.2-1

Comment 6 Tim Waugh 2001-08-06 18:40:07 UTC
Tested; didn't work.

Comment 7 Tim Waugh 2001-08-07 10:36:20 UTC
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 13:12:36 UTC
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 16:06:31 UTC
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 14:55:14 UTC
Ok. Stupid bug in famd. Upgrading to fam-2.6.4-9 should fix this.

Comment 11 Bernhard Rosenkraenzer 2001-08-09 20:48:03 UTC
*** Bug 51319 has been marked as a duplicate of this bug. ***

Comment 12 Alexander Larsson 2001-08-10 15:37:39 UTC
*** 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.