Red Hat Bugzilla – Bug 818935
Occasionally can't reboot/power off because "other users are logged in", even though they are not
Last modified: 2012-10-31 08:28:14 EDT
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):
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
User can't be deleted because he is still logged in
User should be logged out correctly
--- Additional comment from email@example.com 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 firstname.lastname@example.org 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 email@example.com 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 firstname.lastname@example.org 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 email@example.com 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 firstname.lastname@example.org 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
--- Additional comment from email@example.com on 2012-04-27 21:44:21 EDT ---
Filed a patch upstream: https://bugzilla.redhat.com//show_bug.cgi?id=814690
--- Additional comment from firstname.lastname@example.org on 2012-04-30 08:31:19 EDT ---
--- Additional comment from email@example.com 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 firstname.lastname@example.org on 2012-05-02 07:32:32 EDT ---
Created attachment 581585 [details]
(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 email@example.com 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 firstname.lastname@example.org 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:
"after run updater gui cant logout/reboot without
entering administrator password"
--- Additional comment from email@example.com on 2012-05-03 13:18:48 EDT ---
I can't reproduce bug 804361. Don't know whether it is related.
--- Additional comment from firstname.lastname@example.org 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 email@example.com 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
--- Additional comment from firstname.lastname@example.org 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 email@example.com on 2012-05-03 13:56:17 EDT ---
accountsservice has been changed to delete users with prejudice now:
--- Additional comment from firstname.lastname@example.org 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 email@example.com on 2012-05-03 16:47:25 EDT ---
accountsservice-0.6.19-1.fc17 has been submitted as an update for Fedora 17.
--- Additional comment from firstname.lastname@example.org on 2012-05-03 23:11:26 EDT ---
* 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:
then log in and leave karma (feedback).
--- Additional comment from email@example.com 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 firstname.lastname@example.org on 2012-05-04 06:52:19 EDT ---
This is caused by the FALSE -> TRUE change in
we explicitly call daemon_local_user_is_excluded with a NULL shell when dealing with wtmp entries...
I have seen this again. After user logs out, sometimes there is some remnant process. I have seen deja-dup-monitor to stay running. I have also seen pulseaudio --start or gnome-keyring-daemon --daemonize --login, however these ones terminates after few seconds automatically. deja-dup-monitors stays active after log out only sometimes, but it doesn't terminate automatically. But even after I killed it, I still wasn't able to reboot (without providing password).
systemd-loginctl list-sessions reports only gdm and root to have active sessions. (Obviously root is there because I need to log in to tty to execute the command, but I always log out before switching to gdm to try to reboot). gdm was listed twice, running on two ttys (for whatever reason). I restarted prefdm.service to have gdm running only once, didn't help, still can't reboot.
Created attachment 582124 [details]
gdm password request
This is how it looks like (in the background there is a user list with one user, there should be two users, that caused by an unrelated bug).
Created attachment 582126 [details]
Discussed at 2012-05-07 QA meeting acting as a blocker review meeting, rejected as a blocker as it happens so infrequently, is usually not a big problem (most affected users will have the root password), and can be fixed with an update.
Fedora Bugzappers volunteer triage team
Let's fold this back into bug 814690 since they're both probably caused by the systemd issue.
*** This bug has been marked as a duplicate of bug 814690 ***