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:
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.
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.
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.
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.
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.
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
Filed a patch upstream: https://bugzilla.redhat.com//show_bug.cgi?id=814690
http://bugzilla.gnome.org/show_bug.cgi?id=675006
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.
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.
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...
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"
I can't reproduce bug 804361. Don't know whether it is related.
c'ing Richard, then. One useful piece of data would be the output of systemd-loginctl list-sessions
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
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
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
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.
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
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).
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.
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...
I have cloned this bug into bug 818935. This one will be used for user deletion issues. Bug 818935 will be used for reboot/poweroff issues.
(In reply to comment #22) > 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... Matthias, there must be a bug somewhere. See feedback on the Bodhi page. Definitely broken.
Dropping the F17Blocker nomination from this bug, as it's the logout issue that is nominated as a blocker, and also making it not 'block' the clone (I _hate_ how clones are always considered to be blocked by the bug they're cloned from). -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
(In reply to comment #16) > 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 One more thing. It is true that sometimes deja-dup-monitor keeps running even after logout. But usually it is not. However the user still can't be deleted. I have confirmed that no process is running under that user and it still can't be deleted. I believe the bug is somewhere else, not with deja-dup-monitor. Matthias, can you try a few more times to reproduce without deja-dup-monitor running? Further question: Is there a reason not to kill all user process when he logs out? Being able to delete logged in users (userdel -f) might not be the best solution here.
accountsservice-0.6.20-1.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/accountsservice-0.6.20-1.fc17
accountsservice-0.6.20-1.fc17 does not fix bug 814690, the error dialog (see bz attachment) is still shown and user is not deleted. There is probably some other check before userdel is called. But I still wonder whether using using userdel --force is the right solution for this.
well using --force isn't the right solution for this, it was just a potentially convenient work around until we figured out the right solution. but it's not even a good work around before of the error dialog.
This seems to be a GDM problem. GDM notices gnome-session exiting, and then starts to clean things up in its slave code. when that finishes the slave code forcefully kills the session worker process before pam_close_session can finish. Still investigating.
Package accountsservice-0.6.20-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.20-1.fc17' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-7308/accountsservice-0.6.20-1.fc17 then log in and leave karma (feedback).
disregard comment 31
So the GDM problem is real, and I commited a fix here: http://git.gnome.org/browse/gdm/commit/?id=09358813114e1c16b1ea02d80327e418a1809486 But it's not the only problem. Actually pam_systemd just does close() on an fd to in pam_close_session() so that's very, very fast. I wouldn't be surprised if under normal conditions the GDM bug doesn't manifest quickly enough to actually be a problem. Now there are two other problems: 1) after logout pulseaudio sticks around for some seconds . This isn't a big deal, except it means that when systemd notices the session going away it sees pulseaudio still running and marks the session in a "lingering" state 2) when pulseaudio goes away, the cgroup logind setup notifies logind (via systemd-cgroups-agent) that the user session is finally done, and then logind looks for the state associated with the session to mop it up (using a function called manager_get_session_by_cgroup()). It can't find it, though, because that cgroup got ripped out the cgroups hashtable when the user logged out (seconds before pulseaudio exited). At least that what I think is happening. I haven't verified all my assumptions yet.
Hmm, if this happens, what is the contents of /run/systemd/users/$UID, where $UID is the numeric uid of the user in question? In that file we store the ids of all open sessions of a user. It appears that this file might be invalid, if a process ends up staying around with the session officially dead?
# This is private data. Do not parse. NAME=johnny STATE=online CGROUP=/user/johnny RUNTIME=/run/user/johnny SESSIONS=36 SEATS=seat0 ACTIVE_SESSIONS=ACTIVE_SEATS= Note the last two keys are munged together into one line
Created attachment 582752 [details] fix up missing new lines This patch fixes up the obvious lack of newlines in the file. It's not sufficient to fix the problem, though.
*** Bug 819357 has been marked as a duplicate of this bug. ***
The problem, I guess, is /run/systemd/users/$UID won't ever get updated when the cgroup finally empties.
Ray, normally the file should actually already be deleted at that point. I am sure there's something even more broken in logind.
attachment 582752 [details] needs-work, the macro changes were wrong.
Created attachment 582782 [details] this seems to fix it for me
*** Bug 818935 has been marked as a duplicate of this bug. ***
See bug 823485 for a related issue.
I fixed the state file write out in git now, that stuff was seriously borked. But there's more to fix...
(for reference that's http://cgit.freedesktop.org/systemd/systemd/commit/?id=9b958eff3fbcc345a72315a9167f6217dd841c40 )
accountsservice-0.6.21-1.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/accountsservice-0.6.21-1.fc17
Package accountsservice-0.6.21-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.21-1.fc17' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-9407/accountsservice-0.6.21-1.fc17 then log in and leave karma (feedback).
accountsservice-0.6.21-1.fc17 doesn't fix the problem for me. I still get prompted to authenticate for shutdown.
accountsservice-0.6.21-2.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/accountsservice-0.6.21-2.fc17
I assume this is fixed now. Closing.
It is almost fixed in F17. If I log in and log out as 'tester' user, one process survives: /usr/bin/pulseaudio --start But it quits after ~15 seconds, so the user can be deleted pretty soon. The situation is much worse in F18. After I log in and log out as 'tester' user, I see following processes still running: /usr/bin/pulseaudio --start /usr/bin/spice-vdagent /usr/libexec/deja-dup/deja-dup-monitor /usr/libexec/tracker-store /usr/libexec/tracker-miner-fs The big problem is that those processes don't end (I waited ~10 minutes), so the user can't be deleted without reboot (or manually killing them). Also, "loginctl list-sessions" lists 'tester' as active at seat0. Neither 'w' nor 'who' list 'tester'. Reopening for F18. systemd-188-3.fc18.i686 acountsservice-0.6.22-3.fc18.i686
This message is a reminder that Fedora 18 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 18. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '18'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 18's end of life. Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 18 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 18's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
I did a quick test and it seems to be fixed in Fedora 20.