users-admin hangs when run as root

for any other admin user (not root) it works fine

I am seeing the same behavior on Maverick. On a different machine with a new Lucid install, users-admin works fine.

In addition, when I run users-admin with a normal user account, nothing happens when I click on the Add, Delete, and Advanced Settings buttons.

Nothing is written to stdout or stderr when I do this.

users-admin is part of this package.

Reverting to gnome-system-tools 2.30.0-0ubuntu2 (from Lucid) does make a difference. I also needed to install liboobs-1-4 2.30.0-0ubuntu1.

It eventually works, but outputs this warning:
(users-admin:3551): Liboobs-WARNING **: There was an unknown error communicating asynchronously with the backends: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.

That may be unrelated, however.

Sorry, but we don't support logging in as the root user. This is highly unsecure and strongly discouraged. I'm not sure what may be happening, but it's possible something like a D-Bus policy is blocking messages from being sent to root. You may want to have a look at /var/log/auth.log for such errors, but nobody will fix the program for this to work - and I really don't see the need for such a usage...

Milan, I was talking about running "gksu users-admin" rather than logging into a session as root. It is not obvious why that use-case would not be supported.

At least one other user is seeing the same:
http://ubuntuforums.org/showthread.php?t=1585421

"In addition, when I run users-admin with a normal user account, nothing happens when I click on the Add, Delete, and Advanced Settings buttons."

What I mean is that it is the *primary* normal user account that I created during installation. This seems like a clear regression from Lucid, and I would like some help debugging it.

I just created bug #667151 which may be related.

No, using gksu is a deprecated method for a long time, instead programs are now run as a normal user, and get admin rights using PolicyKit. In Maverick, this is for example how updates-manager works.

You're not supposed to run 'gksu users-admin', and I really don't see how you'd think of doing so. Just use System->Administration->Users and Groups, or type 'users-admin'.

@Milan: Dude, we all appreciate the great work you're doing.
But stating that you won't correct a bug and tag it as invalid just because you feel people dont program your way is a bit outrageous and reactionary (even if I agree with your "should not log as root" statement...). It is irrelevant that it is better or not to log in as root. Clearly this is a bug, as root is a valid login (whether you like it or not) and it is abnormal that an application which works for other logins must be killed, instead of at least gracefully stating that it is unavailable to root login and shutting itself down.
Sorry, I had to say it. Now it is your right not to fix it, but please do not use this fallacious kind of argument...
Nothing offensive here, as I said we appreciate your work and help on other matters.
Alan.

If you think it's more fair, I can mark it as Triaged. But IMHO that's as fallacious as Invalid since I know I won't fix it and nobody will now that the gst are deprecated upstream.

(Of course, hadn't it been deprecated, the easy fix would have been to exit when we detect user is root. ;-)

I have the same problem on Maverick.
I used root in order to try and delete the guest account.
Have tried both logging in as root and from a normal admin user terminal using: sudo users-admin.
So have instead deleted the guest group instead (which is doable from normal admin user) hoping it will delete the guest login.

Don't run it as root, like I said above, that's all. Anyway, you shouldn't login graphically as root, so either create an admin account for this kind of task, or use the commandline ('deluser guest').

This talk about whether or not I should login as root is killing me. I am in recovery mode since the login for my useraccount doesn't show up and the entire system just hangs in a grey pre-desktop mode. WHY ON EARTH am I able to log on as root graphically anyway if not to administrate things that might be failing? I'd like to administrate the system since I am having difficulties and then the "user setup" is not working since I am topadmin root? I really really don't get that at all.

So what am I suppose to do when in recovery mode? Get commandline support instead?

I am sorry but I just don't get it.

The fact that you can log in as root doesn't mean you should. GDM doesn't show the root user, and the root account is disabled by default on Ubuntu, so you must have found this idea by yourself.

AFAIK, recovery mode only starts a console, so, yes, you should either fix things from the console, or run a graphical session as a normal user. If you're able to run a session as root, you may as well run it as a normal user with admin rights. There's no reason to run a X session as root as it is dangerous and doesn't make anything possible that you can't do as normal session after authentication via PolicyKit. So, maybe logging in graphically as root should be forbidden, yes.

If so many people are upset by this silly bug, just provide a patch, it might be a really simple bug.

I have exactly the same problem, I tried many distributionns based on Ubuntu with this bug.
How could I resolve it?