Bug 818935

Original bug concerned two issues, which are probably not connected:

1) it is impossible to delete a user after you have logged in as that user and logged out

2) sometimes you can't reboot/poweroff computer without providing password of a user placed in the wheel group, because system claims that other users are still logged in. This is very hard to reproduce.

This bug concerns issue #2. Issue #1 is being handled by the original bug report.


+++ This bug was initially created as a clone of Bug #814690 +++

Created attachment 578989 [details]
Screenshot of message after unsuccessful deletion

Description of problem:
I have two users - admin and another one. I log in as admin and then I switch user to the second user (from user menu > switch user). Then I log out and go back to admin user. When I try to remove second user (in system settings > user accoungs) it fails and it says that this user is still logged in (see attached screenshot).

When I go to consol (tty2) and log in as the second user and log out again - everything is OK, I can remove this user.

It seems like when I use gnome log out it "forgot" to do some stuff.

Version-Release number of selected component (if applicable):
gnome-session-3.4.1-1.fc17.x86_64
systemd-44-4.fc17.x86_64
gnome-shell-3.4.1-2.fc17.x86_64


How reproducible:
always

Steps to Reproduce:
1. Log in as admin user
2. From user menu choose 'Switch user'
3. Log in as another user
4. Log out
5. Go back to admin user's session
6. In User accounts administration, try to remove user you switched to
  
Actual results:
User can't be deleted because he is still logged in

Expected results:
User should be logged out correctly

Additional info:

--- Additional comment from kparal on 2012-04-20 08:51:48 EDT ---

Please note that I hit this issue not just when deleting accounts, but also when trying to poweroff computer - it said some other users are still logged in and required administrative password. But Petr wasn't able to reproduce it. I'll try to reproduce it soon.

--- Additional comment from kparal on 2012-04-23 10:12:17 EDT ---

I can reproduce the problem when deleting account in 100%. But I hit the restart/poweroff problem just occasionally. It seems there is no clear reproducer, it depends on some external factors. If you repeat this procedure:

1. Log in as user1 (admin account)
2. Switch to user2 (standard account)
3. Log out from user2, switch back to user1
4. Try to restart/poweroff computer (with or without logging out first)

there is a non-zero change that you'll see a warning "system policy prevents restarting computer while other users are logged in" or similar. If you see this message, it won't go away on subsequent attempts. You have no option but to provide password for the admin account.

The funny thing is that you won't be able to restart/poweroff computer if you are just a standard user and don't know administrative password.

Due to this happening with a non-zero probability (although small), proposing as F17 blocker.

--- Additional comment from kparal on 2012-04-23 10:15:34 EDT ---

Also worth noting as that if you run terminal and see 'w' or 'who' output, the user that can't be removed from control-center (because he's supposedly still logged in) is not listed there.

--- Additional comment from tflink on 2012-04-26 16:14:09 EDT ---

I'm having trouble seeing how this is a blocker - it doesn't seem to violate any of the release criteria and it could be fixed with an update in almost all of the situations I can think of where you'd hit this.

Unless there is something that I'm missing, I'm -1 blocker, -1 NTH on this.

--- Additional comment from kparal on 2012-04-27 03:55:00 EDT ---

The offending criterion is:
"All release-blocking desktops' offered mechanisms (if any) for shutting down, logging out and rebooting must work"

Sometimes, just sometimes, you are unable to shut down/reboot computer if you don't have admin privileges. If we fix the underlying issue (that can be 100% reproduced when trying to delete the user), I believe this 'shut down' issue will be fixed as well.

--- Additional comment from mclasen on 2012-04-27 17:19:54 EDT ---

Here is what I see in /var/log/gdm/:1-greeter.log after the shell crashed on the switch-user login screen:


   JS ERROR: !!!   Exception was: Error: Error invoking Gio.init: Error calling StartServiceByName for net.reactivated.Fprint: GDBus.Error:org.freedesktop.DBus.Error.Spawn.ChildExited: Launch helper exited with unknown return code 157
    JS ERROR: !!!     lineNumber = '0'
    JS ERROR: !!!     fileName = '"gjs_throw"'
    JS ERROR: !!!     stack = '"("Error invoking Gio.init: Error calling StartServiceByName for net.reactivated.Fprint: GDBus.Error:org.freedesktop.DBus.Error.Spawn.ChildExited: Launch helper exited with unknown return code 157")@gjs_throw:0
(null)@/usr/share/gjs-1.0/overrides/Gio.js:242
([object _private_Gio_DBusConnection],"net.reactivated.Fprint","/net/reactivated/Fprint/Manager")@/usr/share/gjs-1.0/overrides/Gio.js:201
FprintManager()@/usr/share/gnome-shell/js/gdm/fingerprint.js:19
()@/usr/share/gnome-shell/js/gdm/loginDialog.js:776
wrapper()@/usr/share/gjs-1.0/lang.js:204
()@/usr/share/gjs-1.0/lang.js:145
()@/usr/share/gjs-1.0/lang.js:239
_createGDMSession()@/usr/share/gnome-shell/js/ui/main.js:96
start()@/usr/share/gnome-shell/js/ui/main.js:221

--- Additional comment from mclasen on 2012-04-27 21:44:21 EDT ---

Filed a patch upstream: https://bugzilla.redhat.com//show_bug.cgi?id=814690

--- Additional comment from mclasen on 2012-04-30 08:31:19 EDT ---

http://bugzilla.gnome.org/show_bug.cgi?id=675006

--- Additional comment from kparal on 2012-05-02 07:21:47 EDT ---

Matthias, are you sure this is the same bug? It happened for me right now on a machine with just a single user created. I can't reboot until I provide admin password. When I log as root into tty3 and run 'who', I see just root on tty3 and '(unknown)' on ':0'. I don't see any shell crashes in gdm logs.

--- Additional comment from kparal on 2012-05-02 07:32:32 EDT ---

Created attachment 581585 [details]
logs

$ who
(unknown) :0           2012-05-09 12:07 (:0)
root     tty3         2012-05-09 12:08

Attaching logs as a compressed archive, there's quite lot of them. Unfortunately my system date was a bit messed up (set a week in advance), that might be confusing.

--- Additional comment from mclasen on 2012-05-02 09:51:36 EDT ---

No, quite likely that there is a different issue in play here.
I may have also simply confused this bug with a different one that talked about shell crashes on logout...

--- Additional comment from collura on 2012-05-03 01:37:54 EDT ---

this at least seems related or maybe duplicate even 
where for me seems to have something to do with updater:

  https://bugzilla.redhat.com/show_bug.cgi?id=804361
  "after run updater gui cant logout/reboot without 
   entering administrator password"

--- Additional comment from kparal on 2012-05-03 13:18:48 EDT ---

I can't reproduce bug 804361. Don't know whether it is related.

--- Additional comment from mclasen on 2012-05-03 13:22:24 EDT ---

c'ing Richard, then.

One useful piece of data would be the output of systemd-loginctl list-sessions

--- Additional comment from awilliam on 2012-05-03 13:38:07 EDT ---

Discussed at 2012-05-03 blocker review meeting. Agreed that this seems a bit corner case-y, but we will punt at least a week for more data. Obviously inability to shutdown without root password is bad, but unless it can be reproduced more reliably, probably not bad enough to constitute criteria breakage.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

--- Additional comment from mclasen on 2012-05-03 13:42:07 EDT ---

Looks like a deja-dup bug - it leaves a process behind running as the user,
which causes userdel to refuse to delete it. The process is deja-dup-monitor

--- Additional comment from mclasen on 2012-05-03 13:56:17 EDT ---

intentionally:

http://bazaar.launchpad.net/~deja-dup-hackers/deja-dup/24/view/head:/monitor/README 

accountsservice has been changed to delete users with prejudice now:

http://cgit.freedesktop.org/accountsservice/commit/?id=c5905497733bebf9936a7b028a11ca87caf2d71f

--- Additional comment from kparal on 2012-05-03 14:06:44 EDT ---

OK, that will fix user deletion, but won't fix reboot issues. Once I hit that one again, I'll have a look at the process list and hopefully I can find out whether deja-dup-monitor is also responsible for that or not. I'll also gather 'systemd-loginctl list-sessions' output.

Feel free to close this bug with that accountsservice fix and I'll create a new one if needed for the reboot issue.

--- Additional comment from updates on 2012-05-03 16:47:25 EDT ---

accountsservice-0.6.19-1.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/accountsservice-0.6.19-1.fc17

--- Additional comment from updates on 2012-05-03 23:11:26 EDT ---

Package accountsservice-0.6.19-1.fc17:
* should fix your issue,
* was pushed to the Fedora 17 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing accountsservice-0.6.19-1.fc17'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-7276/accountsservice-0.6.19-1.fc17
then log in and leave karma (feedback).

--- Additional comment from robatino on 2012-05-04 01:45:57 EDT ---

After applying accountsservice-0.6.19-1.fc17, my ordinary user name is no longer shown at the GDM prompt. I must use "Not listed?" to log in.

--- Additional comment from mclasen on 2012-05-04 06:52:19 EDT ---

This is caused by the FALSE -> TRUE change in

http://cgit.freedesktop.org/accountsservice/commit/?id=046998a3a5305f381e6e39bc4bf7f69f260856f4

we explicitly call daemon_local_user_is_excluded with a NULL shell when dealing with wtmp entries...