[users-admin] deleting a user doesn't work

i can confirm this, i can even login with the deleted user

Thanks for your report. We need more information to understand how the bug you describe could happen. Please read the instructions at https://wiki.ubuntu.com/DebuggingGnomeSystemTools, and follow the procedure for the tool users-admin.

To reproduce this bug is simple:

1.- Go to System - Administration - Users and Groups
2.- Click on the 'Click to make changes' button and enter your password.
3.- Click on the Add User button, then fill in the Username, Real name, User password and Confirmation fields, then click on the OK button.
4.- Select your new User and then click on the Delete button (after this step, your new User will disappear from the list).
5.- Click on the Close button.
6.- Go to System - Administration - Users and Groups, and you'll see that the user you've deleted is back again.

deluser command works fine.

users-admin.log is empty

What??? I don't understand... when i execute:

sudo killall /usr/bin/perl; sudo /usr/share/system-tools-backends-2.0/scripts/SystemToolsBackends.pl -m UsersConfig -v &> ~/stb-users.log

users-admin works perfectly and deletes the user created, but if I don't execute this command, users-admin doesn't delete the user :S...

i guess something similar happened to me: i created 2 temporary users, and noticed the bug upon deleting them...

but today i noticed that one of these has been deleted (yesterday i launched those command suggested in the wiki), nonetheless i tried again deleting the second user but it still stays there upon logout/reboot...

I have the same problem. I'm unable to delete a user. The dialog removes the user from the users list, but the user is still in the system.

users-admin.log is empty.

I confirm the same behaviour as Jaime Fernando on comment #9: after execute

sudo killall /usr/bin/perl; sudo /usr/share/system-tools-backends-2.0/scripts/SystemToolsBackends.pl -m UsersConfig -v &> ~/stb-users.log

sudo /usr/share/system-tools-backends-2.0/scripts/SystemToolsBackends.pl -m UserConfig -v &> ~/stb-user.log

users-admin works well and really deletes the user.

WORKAROUND: only typing the following command on a gnome terminal and leaving it opened:

$ sudo killall /usr/bin/perl; sudo /usr/share/system-tools-backends-2.0/scripts/SystemToolsBackends.pl -m UsersConfig

Then go to System->Administration->Users and Groups and now you can delete a user.

mmmmmm.... could this be a library bug?

Thanks for the details. Does that happen even if you create the user, restart the computer, and then try to delete it? The only bug I can think of is that we would not be removing users that were just created during the current session.

@Milan:

The problem appeared me when I tried to delete a user I had created several months ago, so obviously I restarted the computer several times between the user creation and the user deletion.

I am experiencing this problem too (marked #463582 as duplicate) and my steps to reproduce include a new session - and even a separate user. So this bug seems to be generic for any kind of account deletion, even with the original user created by a clean install of at least Ubuntu 9.10.

The GIDs are the GIDs my users had.

Steps to reproduce:
0. Login as administrative user (GID:1000)
1. Create a new user as Administrator (GID:1001).
2. Reboot.
3. Login as the new administrator.
4. Startup users-admin.
5. Remove the original user (GID:1000).
6. Close 'users-admin' and start it up again. Notice that the original user (GID:1000) is still there.

I submitted this to upstream for my previous bug report. https://bugzilla.gnome.org/show_bug.cgi?id=600056

I'm getting slightly different behaviour.

This is what I did to reproduce:

1. Create user.
2. Log out and log in with new user.
3. Log out of new user account and back into admin account.
4. Try to delete user via "Users and Groups". It warns that the user is still logged in even though they do not show up in the "users" command.
5. Press OK and the user still appears to be deleted.

However, closing and reopening the "Users and Groups" app makes the user still appear and they account is still accessible.

Darren: Then please report this separately, that's likely to be another problem.

@Milan,

The only difference between what I and the others here are experiencing is that I get a dialogue about the user still being logged in. I fail to see how this could conclusively be a separate bug. I haven't tried to use the killall commands that others here have posted because, frankly, I'm too busy trying to iron out all the other quirks that have reared their heads after upgrading to 9.10. Feel free to raise a separate bug on my behalf if you want.

[removed rant about how bad it is that an OS has been released to production with one gaping security hole like this, never mind two].

OK I guess I've found the culprit, which is a stupid-but-major typo. Please apply the attached patch using
sudo patch /usr/share/system-tools-backends-2.0/scripts/Users/Users.pm < [PATH TO FILE]
and report if that fixes the issue for you. Thanks!

Darren: This dialog is itself a major difference which would deserve a separate investigation. Mixing bugs together never helps fixing them. If you don't have the time for that, I won't nag you into doing it. But I can't obviously find out what's going on without more informations. I think the patch for the current bug will partly fix your problem, but the dialog won't disappear...

Sorry, Milan, but unfortunately your patch doesn't solve the problem.

Aside from that, your patch seems to touch the change_user subroutine, instead of del_user, which should have more sense...

Great! Using the info submitted by Milan, I've found a create a patch which solves the user deletion problem for me. Like Milan's one, please apply the attached patch using:

sudo patch /usr/share/system-tools-backends-2.0/scripts/Users/Users.pm < fix-deleting-user.patch

and report if that fixes the issue for you.

The rationale is: users-admin is using deluser command for deleting a user, but (I don't know why) does not work. My patch simply uses userdel command instead, which works as expected.

Sorry, the above command has a typo. The right one is:

sudo patch /usr/share/system-tools-backends-2.0/scripts/Users/Users.pm < fix-deleting-users.patch

(I typed "fix-deleting-user" instead of "fix-deleting-users".)

Yeah!!!! applying the patch (submitted by Ricardo) to the source of system-tools-backends works very nice.
This is what i did:
1.- sudo apt-get source system-tools-backends and decompress it.
2.- sudo patch /home/jfoc/system-tools-backends-2.8.2/Users/Users.pm < ../Descargas/fix-deleting-users.patch
3.- sudo ./configure && sudo make && sudo make install
4.- Delete an user using users-admin.
5.- close or restart, and you'll see that the user you've tried to delete is gone.

Yeah, I was aware the patch was not about the very same problem, but I preferred testing that one too, since the problem here is very strange - some cleaning is always helpful.

So you say using userdel solves the issue. Are you completely sure of that? I.e., does that work even when rebooting after having created the user? Anyway deluser is a better approach since it takes into account more system parameters and is more user-friendly. The weird thing is that userdel seems to work when you start the tools manually, so...

Jaime: You don't have (and shouldn't, for testing purposes at least) to install the system-tools-backends from sources to apply the patch. If you do so, we can't be sure if the bug is solved by using a custom install, or because of the patch itself. Moreover, I fail to see how your procedure can have fixed the bug, provided that the default install path is /usr/local, where users-admin won't look for the scripts (since D-BUS should not know about them). Or did it overwrite the default D-BUs configuration in /usr/share/dbus-1/?

Could somebody provide the following informations without using the patch (you can revert using patch's -R option) nor a custom install?
- output of 'sudo which perl'
- output of 'ps ax | grep perl', 'ps ax | grep .p', 'ps ax | grep system-tools' after having started users-admin from a fresh boot
- output of 'sudo which system-tools-backends', and of 'sudo system-tools-backends' after reproducing the user deletion attempt, and from fresh boot. Does that fix the problem too?
Thanks!

I've reinstalled Ubuntu again!
The following is from a fresh reboot:

1.- 'sudo which perl' output:
-----------------------------------------------------------------------------------------------------
/usr/bin/perl
-----------------------------------------------------------------------------------------------------
2.- users-admin started.

3.- 'ps ax | grep perl' output:
-----------------------------------------------------------------------------------------------------
 1847 ? S 0:00 /usr/bin/perl /usr/share/system-tools-backends-2.0/scripts/SystemToolsBackends.pl -m Platform
 1853 ? S 0:00 /usr/bin/perl /usr/share/system-tools-backends-2.0/scripts/SystemToolsBackends.pl -m UsersConfig
 1855 ? S 0:00 /usr/bin/perl /usr/share/system-tools-backends-2.0/scripts/SystemToolsBackends.pl -m GroupsConfig
 1857 ? S 0:00 /usr/bin/perl /usr/share/system-tools-backends-2.0/scripts/SystemToolsBackends.pl -m UserConfig
 1865 pts/0 R+ 0:00 grep --color=auto perl
-----------------------------------------------------------------------------------------------------

4.- 'ps ax | grep .p' output :
-----------------------------------------------------------------------------------------------------
    7 ? S< 0:00 [cpuset]
    8 ? S< 0:00 [khelper]
   13 ? S< 0:00 [kacpid]
   14 ? S< 0:00 [kacpi_notify]
   15 ? S< 0:00 [kacpi_hotplug]
   18 ? S< 0:00 [ksuspend_usbd]
   24 ? S 0:00 [pdflush]
   25 ? S 0:00 [pdflush]
   26 ? S< 0:00 [kswapd0]
   28 ? S< 0:00 [ecryptfs-kthrea]
   29 ? S< 0:00 [crypto/0]
   36 ? S< 0:00 [kstriped]
   37 ? S< 0:00 [kmpathd/0]
   38 ? S< 0:00 [kmpath_handlerd]
   39 ? S< 0:00 [ksnapd]
  282 ? S< 0:00 [khpsbpkt]
  425 ? S 0:00 upstart-udev-bridge --daemon
  656 ? S< 0:00 [kpsmoused]
  709 ? Ss 0:00 dd bs=1 if=/proc/kmsg of=/var/run/rsyslog/kmsg
  728 ? S< 0:00 [pccardd]
  805 ? S< 0:00 [ipw2200/0]
  869 ? Ss 0:00 avahi-daemon: chroot helper
  890 ? Ss 0:00 acpid -c /etc/acpi/events -s /var/run/acpid.socket
  915 ? Ss 0:00 /usr/sbin/kerneloops
  981 ? S 0:00 /sbin/wpa_supplicant -u -s
 1049 ? S 0:00 /usr/lib/gdm/gdm-simple-slave --display-id /org/gnome/DisplayManager/Display1
 1050 ? Ss 0:00 /usr/sbin/cupsd -C /etc/cups/cupsd.conf
 1051 tty7 Ss+ 0:08 /usr/bin/X :0 -br -verbose -auth /var/run/gdm/auth-for-gdm-9I5Vxt/database -nolisten tcp vt7
 1147 ? S 0:00 /usr/lib/hal/hald-addon-ipw-killswitch
 1217 ? S 0:00 hald-addon-input: Listening on /dev/input/event1 /dev/input/event0 /dev/input/event2 /dev/input/event5 /dev/input/event4
 1225 ? S 0:00 hald-addon-storage: polling /dev/sr0 (every 2 sec)
 1231 ? S 0:00 /usr/lib/hal/hald-addon-cpufreq
 1232 ? S 0:00 hald-addon-acpi: listening on acpid socket /var/run/acpid.socket
 1338 ? S 0:00 /usr/lib/devicekit-power/devkit-power-daemon
 1473 ? Ss 0:00 /u...

I forget to tell you that the user is still there.

Thanks Jaime! I've been a little stupid asking for 'ps ax | grep .p' because it prints much noise too, but the information is interesting. If others want to try, you can concentrate on the simple step 'sudo system-tools-backends -v', since everything else seems to be fine.

The message
CRITICAL **: Could not get a valid destination, original one was: /
is particularly important and could explain the whole issue. I'll investigate in that direction and report.

Could you confirm though that 'sudo which system-tools-backends' once reported nothing at all? I can't believe it, that would mean something very strange is going on.

I repeated the whole procedure again and:
10.- 'sudo which system-tools-backends' output is:
/usr/sbin/system-tools-backends

OK, this sound more logical.

Any chance you could run the system-tools-backends in gdb to identify the precise source of the error? You should install the debug packages for your version (2.8.2-1) and architecture from
http://ddebs.ubuntu.com/pool/main/s/system-tools-backends/
Then you should run
sudo G_DEBUG="fatal_criticals" gdb system-tools-backends
which will make the program abort on the waring. Then you can type 'ba' to get the trace. Please paste it here - you can then quit using 'q' and 'y'.

ok, this is what i got:

jaime@Sion:~$ sudo G_DEBUG="fatal_criticals" gdb system-tools-backends
GNU gdb (GDB) 7.0-ubuntu
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i486-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Leyendo símbolos desde /usr/sbin/system-tools-backends...Leyendo símbolos desde /usr/lib/debug/usr/sbin/system-tools-backends...hecho.
(no debugging symbols found)...hecho.
(gdb) run
Starting program: /usr/sbin/system-tools-backends
[Thread debugging using libthread_db enabled]

** CRITICAL **: Could not get a valid destination, original one was: /
aborting...

Program received signal SIGABRT, Aborted.
0x009b8422 in __kernel_vsyscall ()
(gdb) ba
#0 0x009b8422 in __kernel_vsyscall ()
#1 0x003174d1 in raise () from /lib/tls/i686/cmov/libc.so.6
#2 0x0031a932 in abort () from /lib/tls/i686/cmov/libc.so.6
#3 0x00207036 in g_logv () from /lib/libglib-2.0.so.0
#4 0x00207066 in g_log () from /lib/libglib-2.0.so.0
#5 0x0804b4f0 in dispatch_stb_message (dispatcher=<value optimized out>,
    message=0x8056940, serial=<value optimized out>) at dispatcher.c:427
#6 0x0804bb1b in dispatcher_filter_func (connection=0x8055070,
    message=0x8056940, data=0x8053e00) at dispatcher.c:608
#7 0x002c3c8d in dbus_connection_dispatch () from /lib/libdbus-1.so.3
#8 0x0011775d in ?? () from /usr/lib/libdbus-glib-1.so.2
#9 0x001fce78 in g_main_context_dispatch () from /lib/libglib-2.0.so.0
#10 0x00200720 in ?? () from /lib/libglib-2.0.so.0
#11 0x00200b8f in g_main_loop_run () from /lib/libglib-2.0.so.0
#12 0x0804bf64 in main (argc=1, argv=0xbffff844) at main.c:121
(gdb) q
A debugging session is active.

 Inferior 1 [process 2831] will be killed.

Quit anyway? (y o n) y
jaime@Sion:~$

I've installed system-tools-backends-dbgsym_2.8.2-1_i386.ddeb before.

Good. Yet another step and we should know where the problem really comes from - it seems to be a D-Bus problem.

Could you try 'sudo G_DEBUG="fatal_criticals" gdb system-tools-backends' again, but then do:
break get_destination
run

and when the breakpoint is reached
print dbus_message_get_path (message)
print dbus_message_get_interface (message)
print dbus_message_get_sender (message)
print dbus_message_get_signature (message)
print dbus_message_get_error_name (message)

Then enter 'next' until the program aborts (should take about 10 lines). If it exceeds 20 lines, then use 'continue' to get to the next message and repeat the procedure from the above 'print' calls.

Ok Milan, this is what i got ;)
jaime@Sion:~$ sudo G_DEBUG="fatal_criticals" gdb system-tools-backends
[sudo] password for jaime:
GNU gdb (GDB) 7.0-ubuntu
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i486-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/sbin/system-tools-backends...Reading symbols from /usr/lib/debug/usr/sbin/system-tools-backends...done.
(no debugging symbols found)...done.
(gdb) break get_destination
Breakpoint 1 at 0x804b296: file dispatcher.c, line 297.
(gdb) run
Starting program: /usr/sbin/system-tools-backends
[Thread debugging using libthread_db enabled]

Breakpoint 1, get_destination (message=0x8056940) at dispatcher.c:297
297 dispatcher.c: No such file or directory.
 in dispatcher.c
(gdb) print dbus_message_get_path (message)
$1 = 134572544
(gdb) print dbus_message_get_interface (message)
$2 = 134572576
(gdb) print dbus_message_get_sender (message)
$3 = 134572648
(gdb) print dbus_message_get_signature (message)
$4 = 2529211
(gdb) print dbus_message_get_error_name (message)
$5 = 0
(gdb) next
294 in dispatcher.c
(gdb) next
297 in dispatcher.c
(gdb) next
300 in dispatcher.c
(gdb) next
304 in dispatcher.c
(gdb) next
309 in dispatcher.c
(gdb) next
311 in dispatcher.c
(gdb) next
312 in dispatcher.c
(gdb) next
dispatch_stb_message (dispatcher=<value optimized out>, message=0x8056940,
    serial=<value optimized out>) at dispatcher.c:425
425 in dispatcher.c
(gdb) next
422 in dispatcher.c
(gdb) next
425 in dispatcher.c
(gdb) next
427 in dispatcher.c
(gdb) next

** CRITICAL **: Could not get a valid destination, original one was: /
aborting...

Program received signal SIGABRT, Aborted.
0x0065a422 in __kernel_vsyscall ()
(gdb)

Wow, not very verbose, but at least now we know that there was not error, and that message destination was set (because it took you 7 'next' to get out of the function). So it seems that the problem is only that the destination was different from org/freedesktop/SystemToolsBackends/*.

Could you break at get_destination() again, type 'next', and then
print arr[0]
print arr[1]
print arr[2]
print arr[3]
print arr[4]

But just before running gdb, please also run 'sudo dbus-monitor --system' and post the output here. This will give us a better idea of what's the message that triggers this. Thanks again for those long investigations!

Ok Milan, this is (i think) a very detailed info:

'sudo dbus-monitor --system' output:
------------------------------------------------------------------------------------------------------------------
signal sender=org.freedesktop.DBus -> dest=:1.61 serial=2 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameAcquired
   string ":1.61"
method call sender=:1.53 -> dest=:1.61 serial=278 path=/; interface=org.freedesktop.DBus.Introspectable; member=Introspect
signal sender=org.freedesktop.DBus -> dest=(null destination) serial=7 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameOwnerChanged
   string ":1.62"
   string ""
   string ":1.62"
signal sender=org.freedesktop.DBus -> dest=(null destination) serial=8 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameOwnerChanged
   string "org.freedesktop.SystemToolsBackends"
   string ""
   string ":1.62"
signal sender=org.freedesktop.DBus -> dest=(null destination) serial=9 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameOwnerChanged
   string ":1.63"
   string ""
   string ":1.63"
------------------------------------------------------------------------------------------------------------------

'sudo G_DEBUG="fatal_criticals" gdb system-tools-backends' output:
------------------------------------------------------------------------------------------------------------------
jaime@Sion:~$ sudo G_DEBUG="fatal_criticals" gdb system-tools-backends
[sudo] password for jaime:
GNU gdb (GDB) 7.0-ubuntu
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i486-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/sbin/system-tools-backends...Reading symbols from /usr/lib/debug/usr/sbin/system-tools-backends...done.
(no debugging symbols found)...done.
(gdb) break get_destination
Breakpoint 1 at 0x804b296: file dispatcher.c, line 297.
(gdb) run
Starting program: /usr/sbin/system-tools-backends
[Thread debugging using libthread_db enabled]

Breakpoint 1, get_destination (message=0x80567e8) at dispatcher.c:297
297 dispatcher.c: No such file or directory.
 in dispatcher.c
(gdb) print arr[0]
Cannot access memory at address 0x0
(gdb) next
294 in dispatcher.c
(gdb) print arr[0]
Cannot access memory at address 0x0
(gdb) next
297 in dispatcher.c
(gdb) print arr[0]
Cannot access memory at address 0x0
(gdb) next
300 in dispatcher.c
(gdb) print arr[0]
Cannot access memory at address 0x0
(gdb) next
304 in dispatcher.c
(gdb) print arr[0]
$1 = (gchar *) 0x0
(gdb) print arr[1]
$2 = (gchar *) 0x0
(gdb) print arr[2]
$3 = (gchar *) 0x0
(gdb) print arr[3]
$4 = (gchar *) 0x11 <Address 0x11 out of bounds>
(gdb) print arr[4]
$5 = (gchar *) 0x2f <Address 0x2f out of bounds>
(gdb) next
309 in dispatcher.c
(gdb) print arr[0]
$6 = (gchar *) 0x0
(gdb) print arr[1]
$7 = (gchar *) 0x0
(gdb) print arr[2]
$8 = (gc...

Yeah, very detailed, now I'm sure the path is '/' and not something strange. dbus-monitor seems to indicate that this wrong message is actually D-Bus introspection asking for an answer, so nothing very problematic. I don't know why I don't see it here, maybe I've not updated my system enough.

What do you get if you run 'sudo dbus-monitor --system' and then reproduce the problem of removing an user as you would normally do? Is the user removed if you run 'sudo system-tools-backends -v' before doing trying (forget about dbus-monitor there)?

Painful debugging, yet it seems to hit many people...

This is what i've done:
1.- sudo dbus-monitor --system
2.- loaded users-admin and deleted the user.

here is the output of 'sudo dbus-monitor --system':

signal sender=org.freedesktop.DBus -> dest=:1.62 serial=2 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameAcquired
   string ":1.62"
method call sender=:1.54 -> dest=:1.62 serial=278 path=/; interface=org.freedesktop.DBus.Introspectable; member=Introspect
signal sender=org.freedesktop.DBus -> dest=(null destination) serial=7 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameOwnerChanged
   string ":1.63"
   string ""
   string ":1.63"
signal sender=org.freedesktop.DBus -> dest=(null destination) serial=8 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameOwnerChanged
   string ":1.64"
   string ""
   string ":1.64"
signal sender=org.freedesktop.DBus -> dest=(null destination) serial=9 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameOwnerChanged
   string ":1.65"
   string ""
   string ":1.65"
signal sender=org.freedesktop.DBus -> dest=(null destination) serial=10 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameOwnerChanged
   string "org.freedesktop.SystemToolsBackends"
   string ""
   string ":1.65"
signal sender=org.freedesktop.DBus -> dest=(null destination) serial=11 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameOwnerChanged
   string ":1.66"
   string ""
   string ":1.66"
signal sender=org.freedesktop.DBus -> dest=(null destination) serial=12 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameOwnerChanged
   string ":1.67"
   string ""
   string ":1.67"
signal sender=org.freedesktop.DBus -> dest=(null destination) serial=13 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameOwnerChanged
   string "org.freedesktop.SystemToolsBackends.Platform"
   string ""
   string ":1.67"
signal sender=org.freedesktop.DBus -> dest=(null destination) serial=14 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameOwnerChanged
   string ":1.68"
   string ""
   string ":1.68"
signal sender=org.freedesktop.DBus -> dest=(null destination) serial=15 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameOwnerChanged
   string ":1.69"
   string ""
   string ":1.69"
signal sender=org.freedesktop.DBus -> dest=(null destination) serial=16 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameOwnerChanged
   string ":1.70"
   string ""
   string ":1.70"
signal sender=org.freedesktop.DBus -> dest=(null destination) serial=17 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameOwnerChanged
   string "org.freedesktop.SystemToolsBackends.UserConfig"
   string ""
   string ":1.70"
signal sender=org.freedesktop.DBus -> dest=(null destination) serial=18 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameOwnerChanged
   string "org.freedesktop.SystemToolsBackends.GroupsConfig"
   string ""
   string ":1.68"
signal sender=org.freedesktop.DBus -> dest=(null destination) serial=19 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameOwnerChanged
 ...

Good news guys! I've been able to reproduce the bug (no idea why I wasn't seeing it before), which actually has nothing to do with the error we were seeing.

The problem comes from the deluser command that does not set the PATH it is using to find the userdel command, which is used in the end to removed the user. Since when run through D-Bus, the system-tools-backends do not pass any PATH to deluser, it was not working - while using sudo inherited the original user's PATH.

This is a minor mistake that could also lead to trouble if the user PATH was set to something funny, since deluser could end up running unwanted commands. Not very likely, but absolutely wrong. Attached is a patch that merely copies what adduser already does, i.e. setting the PATH to something correct to avoid all those issues. You can apply it using
sudo patch /usr/sbin/deluser < [PATH TO THE FILE]

I think it also applied for a Stable Release Update, since users deletion is completely broken using the GUI.

Patch to backport. I can see no problem in making an SRU of it, since this is a very minor change, which is already used by adduser. This could also fix other non-standard use cases where PATH is not set.

It works very well !!!
Thank you so much!!! ;)

Ah, nice work Milan!

This makes a lot of sense, thanks Milan!

I forwarded the patch to Debian (will link the bug once it gets processed), and sponsored the patch.

Accepted into karmic-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

SRU confirmation.

With 3.110ubuntu6 from karmic I'm unable to delete users using the 'Users and Groups' tool. After installing 3.110ubuntu7 from karmic-proposed I can now successfully remove users using the 'Users and Groups' tool.

I've reinstalled adduser (3.110ubuntu6) before because i've applied the patch before, but now, after installing adduser (3.110ubuntu7), I can confirm that I can successfully remove users without a problem. Thank you so much ;).

Confirmed to work here, too.

This bug was fixed in the package adduser - 3.110ubuntu7

---------------
adduser (3.110ubuntu7) karmic-proposed; urgency=low

  * deluser: Explicitly set $PATH, so that this also works when being called
    from programs/environment without $PATH (such as D-Bus activated
    backends). This fixes user deletion from gnome-system-tools. Thanks to
    Milan Bouchet-Valat! (LP: #458883)
 -- Martin Pitt <email address hidden> Mon, 09 Nov 2009 10:34:58 +0100

Copied to lucid.

Users must be deleted with sudo deluser username - doesn't work through GUI

This bug was fixed in the package adduser - 3.110ubuntu7

---------------
adduser (3.110ubuntu7) karmic-proposed; urgency=low

  * deluser: Explicitly set $PATH, so that this also works when being called
    from programs/environment without $PATH (such as D-Bus activated
    backends). This fixes user deletion from gnome-system-tools. Thanks to
    Milan Bouchet-Valat! (LP: #458883)
 -- Martin Pitt <email address hidden> Mon, 09 Nov 2009 10:34:58 +0100

i have a problem...pls help me

E: dpkg was interrupted, you must manually run 'sudo dpkg --configure -a' to correct the problem.
E: _cache->open() failed, please report.

Your problem does not belong to this bug, you must create a new bug report.
however, if you've executed 'sudo dpkg --configure -a' and the problem is still there, and you can't install or remove programs using apt-get or aptitude, try deleting the lock file using:
sudo rm /var/cache/apt/archives/lock

I'm getting this symptom in Lucid, with the addition of users-admin crashing with SIGSEGV in oobs_users_config_delete_user(). Same issue or not?

I'm getting this exact same problem in maverick

If needed I'll try to provide a log later

@Dario: please file a new bug for Maverick using

ubuntu-bug adduser

Thanks.

Still experiencing this bug in Natty - deleting a user doesn't actually delete the user. I'm happy to provide logs etc.