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)[7758]: 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): How reproducible: Always 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. Additional info:
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 report.
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, though.......investigating further.
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 kill-able. 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.