Creating an user destroys most of users and groups configuration

[Roger Miller]

Binary package hint: gnome-system-tools

Xubuntu 8.04 Live CD
Processor = AMD-K6 500MHz
RAM = 311MB

Menu Users and Groups:
Users Settings box shows no users. Unlock button is greyed out with text "this action is allowed".
Manage Groups box is also blank.

cat /etc/passwd shows expected full list of users
cat /etc/group shows expected full list of groups

Using GUI, add user "test" with UID of 1000 and administrator profile.
No entry appears in Users Settings box.
No home directory for "test" is created.
cat /etc/passwd now shows only user "ubuntu"
cat /etc/group now shows only groups "root", "nogroup" and "ubuntu"
sudo capability now lost.

Note that the number of users and groups deleted from passwd and group after using the GUI can vary.

Xubuntu CD verified as good and this test works correctly on another PC with a 1GHz Celeron processor and 256MB of ram.

Kubuntu 8.04 Live CD works correctly on AMD-K6 machine, with addition of users via GUI (kuser?) working normally.

Conclusion - While Xubuntu is generally suitable for old hardware, some gnome system tools fail when used with the AMD-K6 processor. Both the live CD and an installed version show the same behaviour.

[Chris Coulson (chrisccoulson)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. Unfortunately we can't fix it, because your description didn't include enough information. You may find it helpful to read "How to report bugs effectively" http://www.chiark.greenend.org.uk/~sgtatham/bugs.html. We'd be grateful if you would then provide a more complete description of the problem.

We have instructions on debugging some types of problems at http://wiki.ubuntu.com/DebuggingProcedures

Could you please try running users-admin from the terminal, and posting the terminal output in to this bug report?

Thanks

[Roger Miller (zill)]

Xubuntu 8.04 Live CD on AMD-K6 terminal output while adding user "test" via GUI...

ubuntu@ubuntu:~$ users-admin

(users-admin:8184): Liboobs-WARNING **: There was an unknown error communicating 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.

(users-admin:8184): Liboobs-WARNING **: There was an unknown error communicating 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.

(users-admin:8184): Liboobs-WARNING **: There was an unknown error communicating 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.
ubuntu@ubuntu:~$

Note that no users are visible in box before or after adding user "test"

Numerous users and groups disappear after adding user "test".
See attached files passwd_orig, group_orig, passwd_new, group_new for details.

[Chris Coulson (chrisccoulson)]

Sorry for the delay in getting back.

First of all, could you try the following in a terminal:

1) apt-get source system-tools-backends
2) cd system-tools-backends-2.6.0
3) ./test-backends.in UsersConfig
...and post the output

Also, could you have a look for any errors in /var/log/syslog or /var/log/messages, particularly related to DBUS. Could you also try booting without 'quiet' and 'splash' to see if there are any error messages during boot.

When you run users-admin, you should see a process with the command line '/usr/bin/perl /usr/share//system-tools-backends-2.0/scripts/SystemToolsBackends.pl -m UsersConfig' appear, as this service should get started by DBUS when you launch users-admin. Can you tell if that is happening?

[Chris Coulson (chrisccoulson)]

Also bare in mind that the 'In Progress' status for a bug report is a special status meaning it has been assigned to a developer and they are actively working on fixing it.

[Roger Miller (zill)]

Thanks for the help Chris. Attached file "testresults 080702" sequentially shows the outcome of the tests however I am unsure about how to interpret the logs regarding this investigation.

I don't quite understand how to look for the "process with the command line '/usr/bin/perl /usr/share//system-tools-backends-2.0/scripts/SystemToolsBackends.pl -m UsersConfig'" I have a basic knowledge of processes (ps and top) but am not sure how to capture a transient process. Could you please clarify.

Apologies for changing the bug status - is there any guide which shows what Launchpad details can be changed by the various categories of users? Maybe it is necessary to lock some items down so that the "wrong" users can't change them ;-)

[Roger Miller (zill)]

Just to check, I tried the Gutsy Xubuntu Live CD today on the AMD-K6 machine and found that the users-admin GUI seemed to work as expected.

The "Users settings" box only lists root and the properties appear OK but it does not show the user "ubuntu". The "Manage Groups" box shows the expected full list. Both /etc/passwd and /etc/group have the expected full lists, including the user "ubuntu".

I added the user "test" via the GUI (as before) and it appeared correctly. Both /etc/passwd and /etc/group were found to have updated correctly.

So, it looks like the current problem was introduced with Hardy :-(

[Nicholas Allen (nick-allen)]

I have just experienced this bug without AMD hardware. So this is nothing spcecific to AMD processor. users-admin is a completely broken piece of rubbish! The system is hosed after using it and can't even reboot. That a bug like this can exist is bad enough (is there so little testing done prior to release?) but no solution to it since Hardy's release is unacceptable!

[Ney Senna (ney-senna)]

Hi,
I have this problem too, but only in work, in my house this NOT happen.
Only In work, i use authentication with LDAP.

The result of the process:
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 7093 0.1 1.1 13664 11956 ? S 10:38 0:00 /usr/bin/perl /usr/share//system-tools-backends-2.0/scripts/SystemToolsBackends.pl -m UsersConfig

I dont see nothing in syslog.

I tried create a user teste, with users-admin and not work. But i see that a group teste was create.
If i use useradd the user teste is create with success.

My system is update.
system-tools-backends -> 2.6.0-0ubuntu7

I post the result of ./test-backends.in UsersConfig, but user teste dont show.

My file /etc/pam.d/common-auth
#
# /etc/pam.d/common-auth - authentication settings common to all services
#
# This file is included from other service-specific PAM config files,
# and should contain a list of the authentication modules that define
# the central authentication scheme for use on the system
# (e.g., /etc/shadow, LDAP, Kerberos, etc.). The default is to use the
# traditional Unix authentication mechanisms.
#
auth optional pam_mount.so
auth sufficient pam_ldap.so use_first_pass
auth required pam_unix.so use_first_pass

[Dimitrios Symeonidis (azimout)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. You reported this bug a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue for you. Can you try with the latest Ubuntu release? Thanks in advance.

[Ney Senna (ney-senna)]

Dimitrios
This is still an issue for me because in my work we only upgrade from a LTS (Long Term Suport) to another LTS.
We have more then 4.000 stations, and can't upgrade always, it's hard. Then we will upgrade only to 10.4 LTS.

Thanks.

[Dimitrios Symeonidis (azimout)]

switching back to confirmed, importance medium

[Dimitrios Symeonidis (azimout)]

reassigning to the liboobs-1-4 package

[Roger Miller (zill)]

Dimitrios: I have retested this with the latest Jaunty (development branch) Live CD and the fault remains similar to my original report with Hardy.

Run users-admin GUI from terminal...

Users Settings box remains blank
Manage Groups box remains blank
Unlock button greyed out with tip "This action is allowed"

Xubuntu 9.04 Live CD on AMD-K6 terminal output while adding user "test" via GUI...

ubuntu@ubuntu:~$ users-admin

(users-admin:22640): Liboobs-WARNING **: There was an unknown error communicating 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.

(users-admin:22640): Liboobs-WARNING **: There was an unknown error communicating 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.

(users-admin:22640): Liboobs-WARNING **: There was an unknown error communicating 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.

ubuntu@ubuntu:~$

Note that no users are visible in box before or after adding user "test".

However, home directory for user "test" is now created BUT...
cat /etc/passwd now shows only users "root", "ubuntu" and "test".
cat/etc/group now shows only groups "root" and "ubuntu".

Numerous users and groups have disappeared from /etc/passwd and /etc/group after adding user "test" via users-admin GUI.

sudo capability is now lost.

[Dimitrios Symeonidis (azimout)]

possibly also related?
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=433159

[Dimitrios Symeonidis (azimout)]

i have installed xfce4 on my intrepid, and users-admin runs beautifully... I still find it hard to believe it's processor-related...

can one of you please try the following?
install the gnome desktop (without booting into it), and then try running users-admin again...
i suspect some dependency on some gnome library

[Roger Miller (zill)]

Using Xubuntu 9.04 Live CD:

gnome-desktop-data is already installed.
Try to install gnome-desktop-environment (including all dependencies) via Synaptic.

Message; "Some of the packages could not be retrieved from the servers" - Continued

Various errors occurred during installation, including "no space left on device".

Running users-admin from terminal and from menu GUI reports "The configuration could not be loaded. You are not allowed to access the system configuration".

Summary: Using the Jaunty Live CD I am unable to "install" gnome desktop, probably due to low PC RAM (311MB) and poor processor spec (AMD-K6 500MHz).

It would be helpful if another Xubuntu user experiencing this problem (and with a better PC!) would try installing gnome desktop and then report progress here.

[Roger Miller (zill)]

I have just received an email from Bug Watch Updater advising:
** Changed in: debian
       Status: Unknown => Fix Released

Debian bug #433159 refers to "network-admin: fails to display any information"
Debian bug #433159 now states "fixed in libnet-dbus-perl 0.33.5-0.1"

However, the users-admin problem detailed above persists with libnet-dbus-perl 0.33.5-1 which is the latest installed version for Xubuntu Hardy (8.04.2).

[Roger Miller (zill)]

A similar problem has now been reported with Ubuntu 8.10 Intrepid Ibex in forum thread http://ubuntuforums.org/showthread.php?t=1095007.

[Michael Cook (michaelcook-mjc)]

I have encountered something very similar to the Ubuntu 8.10 Intrepid thread above. However, on Xubuntu 8.10. I found the passwd and groups files trashed (65534 on some IDs). I have all the latest patches installed, of which there have been a lot lately and perhaps this bug.

I added /etc/udev/rules.d/ custom rules file in part trying to run a usb query as non-root as usb devices couldn't be seen without using sudo. I then restarted udev and immediately lost connectivity as hardware drivers were restarted. On rebooting, I've found that eth0 & eth1 were messed up and network-manager thought they were DHCP, and not static as I'd configured. Using ifconfig they **dont appear** unless you explicitly state: ifconfig eth0, and they dont appear in the network-manager applet window. I removed the custom rules file and rebooted and the system is still messed up. Then if I manually configure eth0 then use 'ping' it ends up giving 'sendmsg not permitted' if I ping anything but eth0 ip addr. I dont know if this is related but it started appearing at the same time.

Replacing 65534s with more sensible numbers hasn't recovered much - maybe some system services came back to life - and opening the users & groups GUI still presents an empty list of users, with only root appearing.

I'd be happy to capture what I can but I have to recover this machine asap and dont have backups beyond the /var/backups/passwd and groups files. It seems most of it is intact but its functionality is being compromised by bogus users & permissions so I'm hoping there is a simple fix-up here?

System is running on: http://www.cappuccinopc.com/light-c7.asp

[Michael Cook (michaelcook-mjc)]

I got my system back. It was also suffering from network being toasted (ipmasq starts up and fences system). Restarting ipmasq after the interfaces are provisioned (by hand) allows networking to work again. Network-Manager applet is a piece of crap and ping not permitted msgs are caused by ipmasq starting up and assuming eth0 and eth1 are internal not external. Not obvious esp when all your user & groups are screwed up in the first place.
(http://ubuntuforums.org/showthread.php?t=1118878)

[Dirk F (fieldhouse)]

I can confirm similar behaviour with Intrepid Xubuntu and kernel 2.6.27-11.

Initially, have the 1 user created at install time (member of admin, adm, etc).

As this user launch the System>Users and Groups menu item. Select Unlock and authenticate. Add a new 'Desktop User'. On committing, the applet stalls for several seconds during which entries can be seen to be removed from /etc/group (eg, repeatedly run 'wc -l /etc/group' in a terminal). No user has been created. The group and passwd files have been ruined, as described in earlier reports.

If a user is created by other means no corresponding entry appears in the U&G list.

Victims of this bug should be aware of the update-passwd, pwconv and grpconv commands which will greatly help to repair the system.

[Dimitrios Symeonidis (azimout)]

Upstream (Debian) has marked this as released. Can someone please confirm it's fixed in latest Ubuntu? Thank you, and good luck!

[Jonathan Thomas (echidnaman)]

Assuming fixed in Karmic due to lack of response. If this proves otherwise, please reopen.

[Roger Miller (zill)]

Xubuntu 9.10 (Karmic Koala) Alpha 5 (02-Sep-2009) Live CD

Starting from GUI:

Menu Users and Groups:
Users Settings box shows no users.
Select "Click to make changes" button, then enter "" (null) password.
Manage Groups box is also blank.

cat /etc/passwd shows expected full list of users (30)
cat /etc/group shows expected full list of groups (58)

Using GUI, add user "test" with UID of 1000 and administrator profile.
Error message: "The configuration could not be saved - an unknown error occurred."
Error message: "System policy prevents modifying the system configuration" and requests a password for root. Try Passwords "" (null), "ubuntu" and "root" but none accepted!
Note that this error identified as from org.freedesktop.systemtoolsbackends.set

No entry appears in Users Settings box.
However, home directory for "test" is created.

cat /etc/passwd now shows only eight users, including the new user "test":
(root, daemon, syslog, messagebus, avahi, haldaemon, ubuntu, test)

cat /etc/group now shows only nine groups:
(root, daemon, audio, nogroup, syslog, messagebus, avahi, haldaemon, ubuntu)

sudo capability now lost.

============================
Starting from terminal:

Result are very similar to starting from the GUI with the addition of this terminal output...

ubuntu@ubuntu:~/Desktop$ users-admin

(users-admin:3423): GLib-GIO-WARNING **: g_simple_async_result_complete() called from
outside main loop!

(users-admin:3423): GLib-GIO-WARNING **: g_simple_async_result_complete() called from
outside main loop!

(users-admin:3423): GLib-GIO-WARNING **: g_simple_async_result_complete() called from
outside main loop!

(users-admin:3423): Liboobs-WARNING **: There was an unknown error communicating 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.

(users-admin:3423): Liboobs-WARNING **: There was an unknown error communicating 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.

(users-admin:3423): Liboobs-WARNING **: There was an unknown error communicating 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.
ubuntu@ubuntu:~/Desktop$

============================
Conclusion:

Fault basically unchanged from that first reported.

Should be re-opened.

[Milan Bouchet-Valat (nalimilan)]

OK, you actually provided a few more interesting informations than before, and they that can help us debugging that. Does this terrible bug only occur when you enter an empty password to authenticate? What do you mean with:
> Try Passwords "" (null), "ubuntu" and "root" but none accepted!
You should not expect those passwords to work, why would they? If you want to work from the live CD, you should set you user password first, and check that you are member of the admin group.

Could you also run
sudo /usr/share/system-tools-backends-2.0/scripts/SystemToolsBackends.pl -m UsersConfig --platform ubuntu-8.04 -v; sudo /usr/sbin/system-tools-backends -nd
before reproducing the procedure you described, from a *fresh boot*. Thanks at lot!

[Roger Miller (zill)]

Background: I originally experienced this problem with an installed version of Xubuntu Hardy (8.04). I established that the Live CD had the same bug. As I do not wish to change my LTS installation at present, I have since tried Live CDs for Jaunty (9.04) and Karmic (9.10) with similar results.

With Live CDs, the default user is "ubuntu" and sudo commands respond to an empty string as a password (""). Following a fresh boot into the Xubuntu Karmic Live CD I have now set a user password for "ubuntu" with the following results:

Use passwd command to change default ubuntu password from "" (null) to "123456789".

cat/etc/groups confirms user "ubuntu" is in groups "adm" (4) and admin(115).

ubuntu@ubuntu:/etc$ sudo /usr/share/system-tools-backends-2.0/scripts/SystemToolsBackends.pl
-m UsersConfig --platform ubuntu-8.04 -v; sudo /usr/sbin/system-tools-backends -nd
begin::Start of work report.
file_locate_tool_success::Found tool [uname].
file_run_pipe_success::Piping command [LC_ALL=C PATH=$PATH:/sbin:/usr/sbin /bin/uname -s 2>
/dev/null |] for reading.
file_locate_tool_success::Found tool [usermod].
file_locate_tool_success::Found tool [userdel].
file_locate_tool_success::Found tool [useradd].
file_locate_tool_success::Found tool [adduser].
file_locate_tool_success::Found tool [deluser].
file_locate_tool_success::Found tool [chfn].
file_locate_tool_failed::Couldn't find tool [pw].

^C
ubuntu@ubuntu:/etc$

As default user "ubuntu", created a new user "test" as detailed in post #24 above.
Entered password of "123456789" when requested.

No entry appears in Users Settings box.
home directory for "test" is created.

cat /etc/passwd now shows sixteen users, but new user "test" is not shown.
cat /etc/group now shows same nine groups:
(root, daemon, audio, nogroup, syslog, messagebus, avahi, haldaemon, ubuntu)

sudo capability again lost. Passwords of both "123456789" and "" (null) are now rejected with message "ubuntu is not in the sudoers file."

[Milan Bouchet-Valat (nalimilan)]

Thanks for these new tests! Something seems weird to me: the commands I asked you to run did not print the messages they should when creating an user. Did you Ctrl+C before creating the user? Maybe I was not clear enough: you should run these commands, and reproduce the procedure without stopping them.

The explanation of the problem is somewhat simple here: if the user list is empty, when creating an user, the tool will try to make system users list match the list it knows about, which is empty. Some deletions must go wrong, and this can eventually stop the user from even creating test. I'd like to fundamentally change this behavior for the next version, but for now we may still fix the bug that makes the list empty.

Another information I'd need: does the message
> (users-admin:3423): Liboobs-WARNING **: There was an unknown error communicating 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.
appear before you try to create the user? If so, please have a look at /var/log/auth.log
and report if you find errors concerning D-BUS (or attach the file). Thanks!

[Roger Miller (zill)]

Thank you for the info Milan. Yes, I did click Ctrl+C before creating the user as the output had apparently stopped. I have now re-run the test with the following results:

After opening users-admin, the "GLib-GIO-WARNING" (x3) appears, together with a GUI error
box "The configuration could not be loaded". When this error box is closed nothing happens.

On repeating the users-admin command, the "GLib-GIO-WARNING" (x3) is repeated but without
the GUI error box. The GUI "Users Settings" box then appears. New password "123456789" then
entered to authenticate changes.

Add new admin user "test" via GUI. This results in the "Liboobs-WARNING",
together with a GUI error box "The configuration could not be saved".

Close error box and new GUI "Authenticate" box appears, with a repeat of the
"Liboobs-WARNING" and GUI error box. Authentication password "123456789" is rejected with
"Authentication Failure" message. Hit enter with no password and close the error box.

This error process is repeated once more, producing the list of "Liboobs-WARNING" three
times in total.

At this point, the "Users Settings" GUI now has the "Add User" button greyed out and no
users are shown in the box.

The last row of the test commands line shows "file_locate_tool_failed::Couldn't find tool
[pw]." No shell prompt is shown.

The last row of the users-admin terminal output is "(users-admin:3498): Liboobs-WARNING **:
There was an unknown error communicating 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." No shell prompt is shown.

Closing the "Users Settings" GUI restores the shell prompt to the users-admin terminal.

However, the test commands terminal remains stopped at the line "file_locate_tool_failed::Couldn't find tool [pw]." The shell prompt can then only be restored with Ctrl+c.

cat /etc/passwd shows 31 users but new user "test" is not shown.
cat /etc/group shows 21 groups, including "ubuntu" but not "test". Also, group "adm" and
"admin" have been deleted. User "ubuntu" is not listed against any of the current groups.

sudo capability again lost. Passwords of both "123456789" and "" (null) are now rejected
with the message "ubuntu is not in the sudoers file."

Complete /var/log/auth.log is attached in file "dbus 090920" but this extract shows the two dbus entries:

Sep 20 10:38:42 ubuntu dbus-daemon: Rejected send message, 0 matched rules;
type="method_return", sender=":1.41" (uid=0 pid=3492 comm="/usr/sbin/system-tools-backends)
interface="org.freedesktop.SystemToolsBackends" member="set" error name="(unset)"
requested_reply=0 destination="org.freedesktop.SystemToolsBackends.GroupsConfig" (uid=0
pid=3521 comm="/usr/bin/perl))
Sep 20 10:38:42 ubuntu dbus-daemon: Rejected send message, 1 matched rules; type="error",
sender=":1.41" (uid=0 pid=3492 comm="/usr/sbin/system-tools-backends) interface="(unset)"
member="(unset)" error name="org.freedesktop.DBus.Error.AccessDenied" requested_reply=0
destination=":1.52" (uid=0 pid=3521 comm="/usr/bin/perl))

[Milan Bouchet-Valat (nalimilan)]

The logs show that all groups are removed when trying to create the user, thus the subsequent failure since 'ubuntu' is not in the 'admin' group. So the problem is, why no users/groups are detected on start. Do the D-Bus errors in auth.log appear before or after you try to create the user? This is a very important point.

The commands did not print much because they have not been used. If an instance of the backends was already running, the second one you started has stayed idle. Please try this, in two different terminals, reproduce the procedure, and post all the logs here:
- in the first window:
sudo killall perl /usr/bin/perl; sudo /usr/share/system-tools-backends-2.0/scripts/SystemToolsBackends.pl -m UsersConfig --platform ubuntu-8.04
- in the other one:
sudo killall system-tools-backends; sudo /usr/sbin/system-tools-backends -nd

[Roger Miller (zill)]

Fresh boot from Live CD. Copy /var/log/auth.log to attached file "auth_no_passwd".

Use passwd command to change default ubuntu password from "" (null) to "123456789". Copy /var/log/auth.log to attached file "auth_new_passwd". Note the "Error attempting to open/unwrap" messages at the end!

Run the two commands in different terminals:
- in the first window:
sudo killall perl /usr/bin/perl; sudo /usr/share/system-tools-backends-2.0/scripts/SystemToolsBackends.pl -m UsersConfig --platform ubuntu-8.04
- in the other one:
sudo killall system-tools-backends; sudo /usr/sbin/system-tools-backends -nd

Run users-admin in a third terminal. The "root" user is now visible in the Users Settings GUI.
Click on the authentication button and enter password "123456789". The "root" user remains visible.

Add new admin user "test" and enter password of "123456789" when requested.
GUI error box appears with message "The configuration could not be saved".
GUI Authenticate box appears with message "System policy prevents modifying the system configuration". Enter password of "123456789".
GUI error box appears again with message "The configuration could not be saved".

"root "and "test" users now visible in the Users Setting GUI. Close Users Settings window.
Terminal outputs from two specified commands attached in files "command1" and "command2".
Terminal output from users-admin command attached in file "usersadmin"

home directory for "test" is created.
cat /etc/passwd now shows full list of 32 users, including new user "test". See attached file "passwd".
cat /etc/group now shows 59 groups, including new user "test".
However, group "admin" only includes "ubuntu", not new user "test". See attached file "group".

Sudo capability for user "ubuntu" now apparently working but no password requested! (Tested by editing a root file with command "sudo nano /etc/hosts.allow")

Copy /var/log/auth.log to attached file "auth_new_user". No dbus entries present.

[Roger Miller (zill)]

Just to clear up any confusion I will reiterate the comments in my original post. I am using an old, slow, AMD-K6 PC. The problem I raised is only apparent with this PC, although it works fine with other applications (albeit s l o w l y ! ). When I have tried the same Live CDs in more powerful PCs, users-admin appears to work correctly.

A practical workaround is to add new users via terminal, rather than GUI, commands.

My concern is that Xubuntu is meant to be suitable for "older" PCs, and I believe that new users could have difficulty resolving the problems if this bug cannot be fixed. It is interesting to note that the Kubuntu Live CD does appear to work correctly in this PC, including the kuser GUI, especially as KDE apps tend to be "heavier" than XFCE/Gnome apps.

My experiences with this bug are that it never gives the same outcome twice, indicating that it is likely to be related to the significant processing delays inherent in old PCs. This is why my original description was "Users-admin fails with AMD-K6 processor".

[Xande (xande1)]

I can confirm that this is still an issue in freshly (from scratch) installed Karmic (9.10), updated to current as of 7 Jan 2010. This is on a fit-PC 1.0, so the statement above in the thread about it being a slow PC applies. Since the technical info has been handled above, I'll add some less-technical, but hopefully useful notes:
* The users and settings applet seems to start up very slowly (even relative to the slow system).
* The hosed groups file causes the administrator to lose sudo ability, requiring a reboot to single-user mode (not possible due to next item), or from a live CD.
* The hosed groups file causes the system not to boot, as dev/pts in mtab has a group= option, and when the group is missing, the mount fails due to "bogus options".
* Since running into this bug on my first install on this machine, I backed up /etc/group and /etc/passwd before using the Users and Groups tool on the reinstall. After the files were hosed, restoring from the backup (via a bootable CD, as sudo was unusable, and the system wouldn't boot from the root HD) fixes everything, not only that, but after restoring from the backup (simply "cp /etc/group.bak /etc/group") and rebooting, the Users and Groups tool works perfectly, and starts up much faster than before (relatively). No idea why.
* Your theory about the bug is correct, as long as the users appear in the list correctly when the Users and Groups tool launches, everything works fine. It is only when the tool launches with a blank users list that there is a problem.

[Milan Bouchet-Valat (nalimilan)]

OK, sorry for the delay Roger. So if I understand correctly, the only way to reproduce this problem is to create a new user when the users list appears empty? That would be logical, since we commit the data we have, which would be empty if it could not be loaded.

But do you mean that the second time you start users-admin, the users list is empty even if you don't get the error message? That would be the real failure here: we should never allow the tool to run if retrieving data failed.

Then, another part of the issue is that the backends seem to be too slow to start before the timeout is reached. That may come from the fact perl needs quite a bit of memory to run, which may need some swapping. That's relatively hard to solve, but at the very least we should display an error, not destroy the system's configuration.

Xande: are you sure users-admin is starts faster after restoring the backup? That seems really strange if the files are the same. One interesting test (for both of you) would be to start the scripts before starting users-admin, and to compare the startup times: start users-admin once, run it again and see the time it needs, then wait for 5 minutes so that the scripts to stop automatically, and restart users-admin to compare. The first time is needed so that the tool is loaded in memory, but it should not be taken as reference for anything.

[Milan Bouchet-Valat (nalimilan)]

This Debian bug is not related at all.

[Roger Miller (zill)]

Thanks for the reply Milan. As I am getting a bit confused as to where to go from here would you please advise exactly what tests I should now run with the Xubuntu Live CD, specifying if I should first set a user password for "ubuntu".

[Milan Bouchet-Valat (nalimilan)]

What I asked Xande to test should be interesting for you too:
One interesting test (for both of you) would be to start the scripts before starting users-admin, and to compare the startup times: start users-admin once, run it again and see the time it needs, then wait for 5 minutes so that the scripts to stop automatically, and restart users-admin to compare. The first time is needed so that the tool is loaded in memory, but it should not be taken as reference for anything.

You don't actually need to do anything other than starting and closing the tool, noting the (approximate) time it needs to be up. Does the users list appear the second time? Is it visible the third time (i.e. after waiting 5 minutes without using users-admin)?

[Roger Miller (zill)]

Milan - I have tried to run the two scripts as requested but there appear to be problems already...

Terminal 1:
ubuntu@ubuntu:~$ sudo killall perl /usr/bin/perl; sudo
/usr/share/system-tools-backends-2.0/scripts/SystemToolsBackends.pl -m U$
perl: no process killed
/usr/bin/perl: no process killed
Can't locate U$.pm in @INC (@INC contains: /usr/lib/perl5 /usr/share//system-tools-backends-2.0/scripts
/etc/perl /usr/local/lib/perl/5.8.8 /usr/local/share/perl/5.8.8 /usr/share/perl5 /usr/lib/perl/5.8
/usr/share/perl/5.8 /usr/local/lib/site_perl .) at
/usr/share/system-tools-backends-2.0/scripts/SystemToolsBackends.pl line 51.
ubuntu@ubuntu:~$

Terminal 2:
ubuntu@ubuntu:~$ sudo killall system-tools-backends; sudo /usr/sbin/system-tools-backends -nd
sudo: /usr/sbin/system-tools-backends: command not found
ubuntu@ubuntu:~$ sudo apt-get install system-tools-backends
Reading package lists... Done
Building dependency tree
Reading state information... Done
system-tools-backends is already the newest version.
0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded.
ubuntu@ubuntu:~$

Note that this is using Xubuntu 8.04.1 live CD.

Please advise what code and/or tests I should run next. Many thanks.

[Milan Bouchet-Valat (nalimilan)]

/usr/share/system-tools-backends-2.0/scripts/SystemToolsBackends.pl -m U$
This is a bad copy/paste: U$ can't work, obviously, that should be UsersConfig.

/usr/sbin/system-tools-backends
Should be /usr/bin/system-tools-backends in 8.04.

Anyway, you don't need to run those to perform the test I suggested. Just run users-admin directly.

Another issue is that I'm absolutely not familiar with the codebase with had in Hardy. If Xande could replicate this test too, that would allow me to be sure the same problem still appears in Karmic. The goal is to fix this for Lucid, there's little chance we can do anything for Hardy at this point.

[Roger Miller (zill)]

Run script in terminal 1:
sudo killall perl /usr/bin/perl; sudo /usr/share/system-tools-backends-2.0/scripts/SystemToolsBackends.pl -m UsersConfig --platform ubuntu-8.04

Run script in terminal 2:
sudo killall system-tools-backends; sudo /usr/bin/system-tools-backends -nd

Run users-admin in terminal 3:
After 50 seconds, Users Settings GUI appears but with no users visible. Close users-admin.

Run users-admin in terminal 3:
After 20 secondis, Users Settings GUI appears with only root user visible. Close users-admin.

Wait 5 minutes, then run users-admin in terminal 3:
After 20 seconds seconds, Users Settings GUI appears but with no users visible. Close users-admin.

Save script outputs from Terminals 1 and 2 to attached file "bugtest_100112".

[Milan Bouchet-Valat (nalimilan)]

OK, so it seems there's a problem when the scripts are not running (first and third times). Error messages from D-Bus are really not expected, that would explain the bug.

Xande, could you reproduce that test too? I'd like to see what this looks like in Karmic, I'm really more familiar with that version. Thanks!

[no!chance (ralf-fehlau)]

Hi @all,

I had the same problem today on Hardy with the latest updates. I did boot with a live CD and restored my password, shadow and group file from by backup. I found out, that there have been 5 lines of characters with hex sequence 0a 41 in the group file. The line before this sequence is repeated thereafter.

I deleted the lines with these characters and users-admin works correctly.
With these line in the group file, users-admin destroys all groups, except the first two lines (root and daemon).

I cant see any DBUS errors in my daemon.log or syslog file.

[Milan Bouchet-Valat (nalimilan)]

no!chance: See bug 160862 rather. This is a know problem that is fixed in Lucid and should be fixed at some point in Hardy too. Though the original issue is that you had weird characters in your /etc/group file, nowadays users-admin shouldn't get crazy when it encounters this kind of thing.

I'm closing this report because of lack of information. There have been many changes in Lucid that mean this bug cannot happen, so that's less of an issue anyway.