FS#30529 - [tracker] does not shutdown when not needed by any user session
Attached to Project:
Arch Linux
Opened by Fritz Heinrichmeyer (Heinrichmeyer) - Wednesday, 04 July 2012, 07:45 GMT
Last edited by Jan de Groot (JGC) - Thursday, 08 November 2012, 21:48 GMT
Opened by Fritz Heinrichmeyer (Heinrichmeyer) - Wednesday, 04 July 2012, 07:45 GMT
Last edited by Jan de Groot (JGC) - Thursday, 08 November 2012, 21:48 GMT
|
Details
Description:
after logging out of gnome-shell session and clicking restart menu entry in gdm a password dialog pops up: "System policy prevents stopping the system when other users are logged in" even if there is no other user logged in. There is no problem in restarting when i switch to a text console and type <ctrl><alt><del> Additional info: * arch linux 64 bit, without testing packages, using gnome-shell 3.4.2, Kernel Linux 3.4.4-2-ARCH, init=/bin/systemd, dropbox * sorry, i am not shure which package to blame. Steps to reproduce: first log out as user, then restart with gdm menu in top right position. |
This task depends upon
Closed by Jan de Groot (JGC)
Thursday, 08 November 2012, 21:48 GMT
Reason for closing: Fixed
Additional comments about closing: Fixed in gvfs-1.4.1-2.
Thursday, 08 November 2012, 21:48 GMT
Reason for closing: Fixed
Additional comments about closing: Fixed in gvfs-1.4.1-2.
Inadequate password dialog when shutting down gnome system.
I don't see a way to edit the title.
Additional info:
the command "users" from a login shell in one of the text consoles apart from the xsession delivers
"(unknown) fritz"
after logging out of gnome-shell and
"fritz fritz"
after logging in in gnome-shell again
whatever, when i do not boot with systemd as init, this bug/error vanishes. Even without systemd, the (unknown) user is visible and somehow the virtual console for X session moves from 7 to 8.
The dependency on systemd then was a random effect? Apart from systemd having to do with it or not:
This is an annoying bug when there are users that do know and don't want to know the root password and are no hackers at all.
PS: If someone would be so kind to change the bug report title ...
After not beeing able to shutdown and logging in again i have to mute the volume to zero and then raise it again to hear sounds again. This is a major irritation for non technical users.
Another Problem?
The Xorg console changes from 7 to 8:
Start gnome session, logout, login again --> the virtual console for Xorg now is on 8 and stays there.
I will post here when i explore a correlation to power save events.
After second login into gnome, "who" shows my login name at tty8 (on first login into gnome on tty7, this change is reliably reproducible). Every additional gnome terminal creates another line, ie:
fritz tty8 2012-07-14 18:26 (:0)
fritz pts/1 2012-07-14 18:29 (:0)
tty8 is the highest tty number i can achieve by loging in/out.
xterm does not create such an entry btw. but i think this is configurable in gnome-terminal settings.
There is a forum thread about similar observations:
https://bbs.archlinux.org/viewtopic.php?id=105595
What then helps is going to a linux-console, typing "some times "pulseaudio --kill" (until there is no more process left), then logging out, then changing to the gdm-session, then shutting down with system menu (top right). At this point shutdown works without further password dialog.
ck-list-sessions
loginctl list-sessions
loginctl show-session X Y Z; X Y Z being the session numbers from "loginctl list-sessions"
Following processes survive quitting the session and inhibit a shutdown from the gdm window without a privileged password:
/usr/bin/pulseaudio --start --log-target=syslog
/usr/lib/pulse/gconf-helper
/usr/lib/tracker/tracker-store
/usr/lib/tracker/tracker-miner-fs
every login/logout cycle generates a new pair of tracker processes
"loginctl list-sessions" gave 3 sessions (2 6 7).
The attachment shows output of
"loginctl show-session 2 6 7".
After logging in again, i have still session 2 and another session 8.
Otherwise, it hangs around for 20 seconds, which may prevent session closure, at least for a short time.
Now, does it still run after logging out the last user session? Please check if it's actually pulseaudio and not something else. If it does, try "pactl list clients".
Maybe this should be a tracker bug now or is there a problem with process management in general?
https://bugzilla.gnome.org/show_bug.cgi?id=681887 tracker bug pointing to
https://bugzilla.gnome.org/show_bug.cgi?id=687074