Comment 29 for bug 458883

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!