GNOME Bugzilla – Bug 681887
Processes remaining after logout when using tracker 0.14.x in gnome 3.5.x
Last modified: 2014-12-15 17:55:45 UTC
Since I've upgraded to gnome 3.5.x stack, tracker is no longer shutting down properly when logging out from gnome session. The remaining processes are tracker-miner-fs and tracker-store, the only processes staying active after logging out (no hints in the logs, no obvious crashes). Currently I'm running tracker 0.14.2 on a gnome 3.5.5+ stack but it happened with earlier versions, too (but not when I was using gnome 3.4). Any hints how to debug this?
Hello Gert. We're not actively listening for the logout to shutdown these services. Given the data is stored on a per-user basis, it likely makes sense. Though we would have to implement this for each desktop manager AFAICS. I am surprised to hear on GNOME 3.5.5 tracker is shutdown automatically. I would guess this is because all processes instantiated by DBus are killed if/when the session is closed. I would need to check to be sure, but that's my hunch. Patches would be welcome on this.
Shouldn't we be able to rely on the session manager to terminate all processes in the session? As long as we correctly handle SIGTERM, I don't see why we'd need any desktop-specific session manager support. I don't know what changed in GNOME 3.5 in that regard, maybe it's simply a bug in gnome-session 3.5?
(In reply to comment #2) > Shouldn't we be able to rely on the session manager to terminate all processes > in the session? As long as we correctly handle SIGTERM, I don't see why we'd > need any desktop-specific session manager support. > > I don't know what changed in GNOME 3.5 in that regard, maybe it's simply a bug > in gnome-session 3.5? I am perhaps a bit dated in this area. In the good old days, (we're talking when I hacked on Gossip so probably > 5 years ago), I am sure there was a signal that was emitted which apps were supposed to listen to. I can't trust my own memory these days though :) - Sounds like you know better these days Jürg. I agree, it would be better if every application didn't have to listen to this signal and react. Re-assign? :) the question is where - lightdm or gdm?
(In reply to comment #3) > I am perhaps a bit dated in this area. In the good old days, (we're talking > when I hacked on Gossip so probably > 5 years ago), I am sure there was a > signal that was emitted which apps were supposed to listen to. I can't trust my > own memory these days though :) - Sounds like you know better these days Jürg. If I remember correctly, this was needed only if the application wants to interrupt the logout process or save the session state. > I agree, it would be better if every application didn't have to listen to this > signal and react. Re-assign? :) the question is where - lightdm or gdm? I don't think the login manager is involved here, I'd expect gnome-session (and in the future possibly systemd) to be responsible for the life time of user processes started in a GNOME session.
tracker-miner-fs should really die when its session bus connection goes away. The fact that it doesn't is a gvfs bug: bug 687074
this bug has severe consequences and should be considered urgent: when tracker-miner-fs is hanging around from a previous session, a user needs administrator password to reboot for i.e. windows gaming. Usability of linux in a "family environment" is severely degraded for this.
Is this fixed now that bug 687074 is fixed?
(In reply to comment #7) > Is this fixed now that bug 687074 is fixed? No reply in 20 months, assuming so.