From Bugzilla Helper:
User-Agent: Mozilla/5.0 Galeon/1.2.0 (X11; Linux i686; U;) Gecko/20020311
Description of problem:
When you try to run the 'User Manager' application from the 'system-settings:'
screen in Nautilus no root prompt is given and the program does not run.
(This happens with a number of the other tools too.)
This error shows in the messages log file: redhat-config-users(pam_unix):
auth could not identify password for [root]
When run from the command line (even in an X terminal) the prompt is not GUI
based, but is just a command line 'Password:' prompt.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Double click 'Start Here' on the desktop
2. Double click 'System Settings'
3. Double click 'User Manager'
Actual Results: Nothing happens (that is apparent to the user)
Expected Results: Root password dialagoue to open and prompt for password, then
user manager to start.
You need to install usermode-gtk. It wasn't getting pulled in by default in
Skipjack because it was left out of the comps file. This has been fixed in the
latest internal trees by adding usermode-gtk to the comps file. Thanks for your
That fixed the fact that the Auth dialogue was not popping up on all of the
'system-settings:' components. But User Manager and Hardware Browser are still
not working. User Manager still works from the command line and will pop up the
GUI Auth window, and run - but when double clicked from Nautilus does not run
and gives no error.
Hardware Browser opens the Auth dialogue and runs a process, but nothing
displays and the process is not kill-able (even with kill -9).
28258 ? R 31:41 /usr/bin/python /usr/share/hwbrowser/DeviceList.py
28259 ? Z 0:00 [python <defunct>]
It also eats up CPU cycles, so it's trying to do something.
Hmm...launching Hardware Browser works just fine for me. User Manager is not
coming up, though. I wonder why launching it from the command line works,
Possibly a bad nautilus descriptor or something?
Some possibilities on the Hardware Browser front:
The 'R' in the process list means it's in the runnable queue. It is also not
These together suggest that it is blocking at the hardware or kernel level
(according to someone in the know). I couldn't attach to the process with gdb -
probably related to the hardware blocking.
Let me know if you have some trick to try and debug this or figure out what's
wrong, I'll run some tests for you.
We've spent about 30 minutes scratching our heads over this and traced it back
to a bug in eel. Basically, you can't write to stdout, so things are breaking.
hp says he has a fix for this, so I'm changing the component to eel and
assigning to hp.
Fix in eel-1.0.2-9
*** Bug 62143 has been marked as a duplicate of this bug. ***
I'm using eel-1.0.2-9, and I'm still seeing the problem.
Nalin's pushing through eel-1.0.2-10 that fixes the problem correctly.