trackerd ingores SIGINT when scanning Evolution email for junk

[TJ]

Binary package hint: tracker

Affects Hardy Intrepid Jaunty

When a trackerd process is running, and is re-indexing Evolution IMAP4 email headers (maybe other scenarios too) in

src/trackerd/tracker-email-evolution.c::check_summary_file()

sending a SIGINT to the process fails to stop the process although the main thread does seem to receive and acknowledge the signal.

$ trackerd &

deleting email email://1172067579.27670.2@hephaestion/Subscribed Lists/video4linux;uid=54
deleting email email://1172067579.27670.2@hephaestion/Subscribed Lists/video4linux;uid=55
deleting email email://1172067579.27670.2@hephaestion/Subscribed Lists/video4linux;uid=56

$ killall -s INT trackerd

Received signal Interrupt
Received signal 'Interrupt' so now shutting down
Total allocations = 835, total deallocations = 835
deleting email email://1172067579.27670.2@hephaestion/Subscribed Lists/video4linux;uid=57
deleting email email://1172067579.27670.2@hephaestion/Subscribed Lists/video4linux;uid=58
deleting email email://1172067579.27670.2@hephaestion/Subscribed Lists/video4linux;uid=59

[TJ (tj)]

Analysis (please allow for context or typo issues, although I hope I've been accurate here with copy/paste):

When the INT signal is received there is code executing in src/trackerd/trackerd.c::process_files_thread():

if( tracker->index_status != INDEX_FINISHED) { ... switch (tracker->index_status) { ... case INDEX_EMAILS:

 if (tracker->index_evolution_emails || tracker->index_kmail_emails || tracker->index_thunderbird_emails) {
  tracker_email_add_service_directories (db_con->emails)

In src/trackerd/tracker-email.c::tracker_email_add_service_directories() it follows:

 if (tracker->index_evolution_emails) {
  if (evolution_init_module ()) {
   evolution_watch_emails (db_con);
  }
 }

In src/trackerd/tracker-email-evolution::evolution_watch_emails () it executes:

 if (store) {
  check_summary_file (db_con, row[2], store);

which leads to src/trackerd/tracker-email-evolution::check_summary_file() where it scans for 'junk' headers and repeatedly executes this loop:

if (scan_summary_for_junk (summary, &uid, store->type)) {
 if (uid > 0) {
  gchar *uri, *str_uid;

  str_uid = tracker_uint_to_str (uid);

  tracker_db_email_insert_junk (db_con, path, uid);

  uri = g_strconcat (store->uri_prefix, str_uid, NULL);

  tracker_db_email_delete_email (db_con, uri);

  g_free (uri);
  g_free (str_uid);

 }

The problem is, where there are a *large* number of existing headers the scanning can take 1/2 hour or more. In the example case:

$ pwd
/home/tj/.evolution/mail/imap/tjworld.net@pella/folders/Subscribed Lists/subfolders/video4linux

 ls *.HEADER | wc -l
2084

In src/trackerd/trackerd.c::signal_handler() it does:

 g_timeout_add_full (G_PRIORITY_LOW, 1, (GSourceFunc) tracker_do_cleanup, g_strdup (g_strsignal (signo)), NULL);

In src/trackerd/trackerd/c::tracker_do_cleanup() it does:

 /* set kill timeout */
 g_timeout_add_full (G_PRIORITY_LOW, 20000, (GSourceFunc) tracker_die, NULL, NULL);

But even after that 20,000 milliseconds tracker_die() doesn't kill the process.

The issue seems to be that src/trackerd/trackerd.c::process_files_thread() does

  sigset_t signal_set;

  sigfillset (&signal_set);

which effectively disables all signals (since signal_set will be initialised to zero by the compiler).

Potentially long-running operations should enable signals and handle them gracefully.

[TJ (tj)]

Working up a patch to deal with this. It is related to bug #239391 "trackerd uses 100% cpu"

[TJ (tj)]

Upstream have applied a patch to fix this.

[Martyn Russell (martyn-lanedo)]

This bug is related to an obsolete version and is no longer valid. It was fixed upstream.

We have disabled support for the Evolution SQLite DB inspection code since it was causing problems with Evolution running and not responding. We have a new method which involves Evolution "pushing" data to Tracker instead and this will be enabled for release 0.6.92 coming this week.