trackerd running under "user" after "user" logs out

[Marcel Hecko]

Tracker starts as user is logged into the system, however keeps running after the user logs out. This is not very convenient when users /home/ dir is remotely mounted and needs to be unmounted when the user logs out. The umount will report "device busy" and lsof will report

root@shmu:~# lsof | grep /home/marcel
trackerd 5672 marcel cwd DIR 0,22 0 2 /home/marcel
trackerd 5672 marcel 3uW REG 0,22 0 19115 /home/marcel/.local/share/tracker/marcel_tracker_lock
trackerd 5672 marcel 4uw REG 0,22 0 19340 /home/marcel/.cache/tracker/file-meta.db
trackerd 5672 marcel 5u REG 0,23 1024 37305 /home/marcel/.cache/tracker/file-meta.db-journal
trackerd 5672 marcel 6r DIR 0,23 0 22687 /home/marcel/.cache/tracker

and therefore the system will keep the dir mounted after the user logs out - this might also be a potential security issue

my installation uses pam_mount to mount remote cifs (smbfs) dirs

sincerely,
Marcel Hecko

[Jamie McCracken (jamiemcc-blueyonder)]

hi,

under normal usage trackerd should exit when dbus session bus closes down (which it should do when you logout as it is user specific)

dbus-session bus should be started after X login and exit when logged out - is this the case?

Another potential problem is that lastest trackerd pauses when it detects external disk activity to minimise slowdown of other apps so it's possible trackerd is sleeping instead of exiting. I will make sure it wont pause when exiting but cant say if that fixes your problem (if you did not have this problem with previous version of tracker then it may well be the case)

[Jamie McCracken (jamiemcc-blueyonder)]

I believe the problem was that tracker had outstanding transactions which prevented a clean kill from occurring

we have fixed this and hopefully should fix your case also

when 0.6.3 version is in gutsy pls retest and reopn bug if problem perists

[Martin Pitt (pitti)]

tracker (0.6.3-0ubuntu1) gutsy; urgency=low

  [ Emilio Pozuelo Monfort ]
  * New upstream release (LP: #130794, #131983, #132320, #137352, #138331,
    #139173, #132505, #131559, #131735, #132710, #133246, #137873, #138778.
  * debian/patches/01-version_fix.patch,
    debian/patches/02-getenv.patch,
    - Removed, fixed upstream.
  * debian/patches/03-system_ioprio.patch: not needed anymore, as tracker
    now tries ioprio system syscalls if available.
  * debian/patches/01_from_upstream_fix_stemming.patch:
    - Added, fixes language selection.

  [ Martin Pitt ]
  * debian/control: Promote o3read to a dependency. That way, updates will get
    it, too, and we avoid making it a dependency of ubuntu-desktop. With the
    external dependency we can avoid installing the internal code copy.

 -- Martin Pitt <email address hidden> Fri, 28 Sep 2007 17:45:16 +0200

[Alessio Caiazza (nolith)]

I've got the same problem on a fresh gutsy installation with pam_mount over encrypted partition.

[Jamie McCracken (jamiemcc-blueyonder)]

ok

whats the status of the process? (tracker-status)

does it respond to kill? (dont do kill -9)

can you attach log in ~/.local/share/tracker

[Alessio Caiazza (nolith)]

How can I obtain the status?
Shoul I try to kill from a root's shell or a user shell?

This is my lsof /home/nolith

[Alessio Caiazza (nolith)]

$ cat tracker.log
29 ott 2007, 17:15:09:397 - ERROR: execution of prepared query CreateService failed due to constraint failed with return code 19
29 ott 2007, 17:15:09:397 - ERROR: CreateService uri is /usr/share//applications/sun-java6-java.desktop
29 ott 2007, 17:15:09:397 - ERROR: could not get file id for /usr/share//applications/sun-java6-java.desktop - unable to continue indexing this file
29 ott 2007, 17:15:09:399 - ERROR: execution of prepared query CreateService failed due to constraint failed with return code 19
29 ott 2007, 17:15:09:399 - ERROR: CreateService uri is /usr/share//applications/sun-java6-javaws.desktop
29 ott 2007, 17:15:09:399 - ERROR: could not get file id for /usr/share//applications/sun-java6-javaws.desktop - unable to continue indexing this file

[Alessio Caiazza (nolith)]

Il giorno lun, 29/10/2007 alle 17.10 +0000, Alessio Caiazza ha scritto:
> How can I obtain the status?

I've installed tracker-utils

$ tracker-status
Tracker daemon's status is �Ë
.

> Shoul I try to kill from a root's shell or a user shell?
$ ps aux | grep tracker
nolith 9161 3.6 0.5 30264 10092 ? SNl 14:28 11:23
trackerd
nolith 17324 0.0 0.0 2988 776 pts/0 R+ 19:43 0:00 grep
tracker
nolith@talbot:~$ kill 9161
nolith@talbot:~$ ps aux | grep tracker
nolith 17326 0.0 0.0 2988 772 pts/0 R+ 19:43 0:00 grep
tracker

$ tracker-status
Tracker daemon's status is Initializing.

May I provide some additional data?

[Jamie McCracken (jamiemcc-blueyonder)]

Is it possible for you to try out svn version of tracker (you will need to compile it)?

we have fixed some hangs and exiting issues but of course I cannot say it resolves your issue

[Alessio Caiazza (nolith)]

I can't be able to reproduce this bug I think it should be caused by
other factors.

I assumed it was a trackerd problem becouse pam_mount never unmount my
home, but is was related to evolution not to trackerd

Oct 30 10:03:25 talbot gdm[7024]: pam_mount(misc.c:264)
command: /usr/bin/lsof [/home/nolith]
Oct 30 10:03:25 talbot gdm[7024]: pam_mount(mount.c:131) lsof output
(should be empty)...
Oct 30 10:03:25 talbot gdm[7024]: pam_mount(mount.c:100) COMMAND PID
USER FD TYPE DEVICE SIZE NODE NAME
Oct 30 10:03:25 talbot gdm[7024]: pam_mount(mount.c:100) gtk-windo 7259
nolith cwd DIR 254,9 4096 128 /home/nolith
Oct 30 10:03:25 talbot gdm[7024]: pam_mount(mount.c:100) evolution 7314
nolith 22u REG 254,9 12288
14680420 /home/nolith/.evolution/addressbook/local/system/addressbook.db
Oct 30 10:03:25 talbot gdm[7024]: pam_mount(mount.c:100) evolution 7314
nolith 23r REG 254,9 131
14681356 /home/nolith/.evolution/addressbook/local/system/addressbook.db.summary

I'll keep my eyes open on this problem, but should be related to some
other causes.

[Jamie McCracken (jamiemcc-blueyonder)]

We have made fixes to prevent hangs which stop it quitting smoothly

[Emilio Pozuelo Monfort (pochu)]

tracker (0.6.4-1ubuntu1) hardy; urgency=low

  * Merge with Debian, remaining Ubuntu changes:
    - debian/control:
      + Addhere to DebianMaintainerField spec.
      + Do not build-depend on universe dependencies:
        libunac1-dev, libqdbm-dev.
      + tracker depends on o3read instead of recommend it, so we have
        OOo indexing by default.
    - debian/rules:
      + Enable sqlite external db instead of qdbm.
    - debian/patches/02_no_kde_autostart.patch:
      + Do not autostart trackerd in Kde, as they have strigi.
    - debian/patches/03_no_initial_index_in_battery.patch:
      + Do not run the initial index if running on battery.
        Patch taken from upstream SVN, revision 1075:
        http://svn.gnome.org/viewvc/tracker?view=revision&revision=1075
    - debian/patches/04_fix_crash_index_name_is_null.patch:
      + Fix a crash when index name is null during merging.
        Patch taken from upstream SVN, revision 1076:
        http://svn.gnome.org/viewvc/tracker?view=revision&revision=1076
    - debian/patches/05_typo_audio_track_peak_gain_tag.patch:
      + Fix a typo in a tag metadata. LP: #145359
        Patch taken from upstream SVN, revision 1077:
        http://svn.gnome.org/viewvc/tracker?view=revision&revision=1077
    - debian/patches/06_trackerd_infinite_loop.patch:
      + Fix an infinite loop in trackerd if a second instance is
        launched. Patch taken from upstream SVN, revision 1079:
        http://svn.gnome.org/viewvc/tracker?view=revision&revision=1079

  * Bugs fixed in the new release:
    - LP: #130935. Added a notification area tool displaying trackerd's
      status, and allowing to search from there.
    - LP: #138331: prevent hangs which stopped tracker quitting smoothly.
    - LP: #147756: Fixed memory leaks.
    - LP: #159807: Stop indexing if disk is full.
    - LP: #164148: Unsafe tempfile usage.
    - LP: #148520: Check for overlapping watch dirs
    - LP: #132463: Always show full path of files in tracker-search-tool.
    - LP: #133402: Do not repeat 'Preferences' in the preferences title.
    - LP: #164412: Limit log size to 10MB.
    - LP: #150814: Detect and prevent database corruption.
    - LP: #160262: Fix evolution email opening for the deskbar handlers.
    - LP: #150030: Show applications in search results.

 -- Emilio Pozuelo Monfort <email address hidden> Fri, 14 Dec 2007 01:16:26 +0100

[Chuck Kollars (chuck-ckollars)]

I had the same problem with gutsy and pam_mount. I found that trackerd is neither the only problem (gtk-window-decorator is too) nor the root cause. Improvements to trackerd exit are welcome and should prevent some unrepeatable failures, but they may not deal with the core problem.

It seems that some processes (trackerd for example) are never even notified of a logout by gdm until after pam_mount tries to do a umount. The code in gdm apparently calls pam_close_session() _before_ it signals processes like trackerd. (Note that pam_mount, which actually does the umount, is called from gdm. And pam_mount is called on to do its thing in the middle of the "logout" process; just saying "logout" is too imprecise.) The pam_mount un-mount process is sufficiently error-prone that I wouldn't be surprised if this problem has come up before in other contexts and has a solution known to pam_mount experts.

One possible long-term solution is to manipulate the order of the code in gdm. This seems the cleanest, but it may risk lots of instability and require lots of testing.

One possible short-term (and very configuration-specific solution) is to add an optional invocation of pam_exec.so in /etc/pam.d/gdm to signal TERM to the offending process _before_ the invocation of pam_mount.so.

A cleaner, more robust solution is to add an optional invocation of pam_script.so in /etc/pam.d/gdm. Then supply a generic script that pam_script.so invokes. The possible problem with this approach is that although Ubuntu contains lots and lots of possible pam modules, it does not include pam_script. Obtaining the source as a tarball then compiling it seems to work fine. But the decision of what to "officially support" and what not may be an issue.

What I did for my short-term solution was used a kludge in pam_mount.conf to call a script rather than having to obtain pam_script.so. [The easy solution of using pam_exec.so doesn't work because the same script would be called for _both_ pam_open_session() and pam_close_session(). My kludge with pam_mount.conf is just a way to activate something only on pam_close_session() but not pam_open_session().]

The relevant lines in my /etc/pam.d/pam_mount.conf look like this:
  ...
 ### hijack these unneeded entries to use them for our kludge instead
 ###fusemount /sbin/mount.fuse %(VOLUME) %(MNTPT) "%(before=\"-o\" OPTIONS)"
 ###fuseumount /usr/bin/fusermount -u %(MNTPT)
 fusemount /bin/true
 fuseumount /usr/local/bin/termallonmount %(MNTPT)
  ...
 ### this is a kludge to call our "helper" - these are not real mounts
 ### this kludge specification goes at the end of the file so it's the last/first thing executed
 volume * fuse cube3 & /home/& - - -

I created the script /usr/local/bin/termallonmount as a fairly normal bash script that loops over the results of an 'lsof` and `kill's things, then `sleep`s for a couple seconds to give all the processes time to cleanup. Just be sure not to rely on any environment variables like $HOME (they don't exist in the pam context), and to use some logic to make sure you don't kill important generic processes (like dhclient, termallonmount [yourself]) no matter what test invocation you...

[toobuntu (toobuntu)]

As you can see below, after used "ed" logs out of a fully updated Gutsy workstation, his trackerd, bonobo-activation-server, and firefox-3.0 processes remain.

nasslaw@uw1:~$ w
 10:14:51 up 6 days, 16:44, 1 user, load average: 0.01, 0.00, 0.00
USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT
nasslaw pts/0 uw5.local 09:12 0.00s 0.24s 0.00s w

nasslaw@uw1:~$ ps aux | grep -v grep | grep ed
root 3660 0.0 0.0 0 0 ? S< Mar27 0:00 [kpsmoused]
ed 8635 0.0 0.7 27832 7484 ? SNl Mar30 0:02 trackerd
ed 9763 0.0 0.3 40036 3232 ? Ssl Mar30 0:00 /usr/lib/bonobo-activation/bonobo-activation-server --ac-activate --ior-output-fd=16
ed 11862 0.0 4.1 179576 42924 ? S Mar31 0:00 /usr/lib/firefox-3.0-3.0b3pre/firefox-3.0

nasslaw@uw1:~$ apt-cache policy tracker libbonobo2-0 firefox-3.0
tracker:
  Installed: 0.6.3-0ubuntu3
  Candidate: 0.6.3-0ubuntu3
  Version table:
 *** 0.6.3-0ubuntu3 0
        500 http://us.archive.ubuntu.com gutsy/main Packages
        100 /var/lib/dpkg/status
libbonobo2-0:
  Installed: 2.20.0-0ubuntu1
  Candidate: 2.20.0-0ubuntu1
  Version table:
 *** 2.20.0-0ubuntu1 0
        500 http://us.archive.ubuntu.com gutsy/main Packages
        100 /var/lib/dpkg/status
firefox-3.0:
  Installed: 3.0~b3~cvs20080101t1000+nobinonly-0ubuntu1~gutsy1
  Candidate: 3.0~b3~cvs20080101t1000+nobinonly-0ubuntu1~gutsy1
  Version table:
 *** 3.0~b3~cvs20080101t1000+nobinonly-0ubuntu1~gutsy1 0
        500 http://us.archive.ubuntu.com gutsy-backports/universe Packages
        100 /var/lib/dpkg/status
     3.0~alpha8+nobinonly-0ubuntu1 0
        500 http://us.archive.ubuntu.com gutsy/universe Packages

nasslaw@uw1:~$ uname -srvmo
Linux 2.6.22-14-generic #1 SMP Tue Feb 12 07:42:25 UTC 2008 i686 GNU/Linux

[Jan Engelhardt (jengelh)]

>I had the same problem with gutsy and pam_mount. I found that trackerd is neither the only problem (gtk-window-decorator is too) nor the root cause.
>It seems that some processes (trackerd for example) are never even notified of a logout by gdm until after pam_mount tries to do a umount.

Then this is a bug in GDM. It should terminate the processes with SIGTERM before unwinding the PAM stack.

>One possible long-term solution is to manipulate the order of the code in gdm. This seems the cleanest, but it may risk lots of instability and require lots of testing.

It needs to do the logout operations in the exact reverse order as the login ones. Failure to do so asks for problems.