increase in number of wakeups in recent release in indicator-datetime

Agreed, I'm seeing similar wakeup numbers when testing with 13.10.0+14.04.20140324.1-0ubuntu1.

So, by adding a breakpoint for g_timeout_dispatch, it does look like gio's im_scan_missing is being called every four seconds. (glib/gio/inotify/inotify-missing.c's inotify_add() calls g_timeout_source_new_seconds(SCAN_MISSING_TIME) where SCAN_MISSING_TIME is #define'd to 4.

inotify-missing is watching for these directories to be created:

  * /usr/share/ubuntu/applications
  * /usr/local/share/applications

The backtrace shows that _im_add() is being called from this path:

#0 _im_add (sub=sub@entry=0x82d5d38) at /build/buildd/glib2.0-2.39.92/./gio/inotify/inotify-missing.c:60
#1 0xb7db2547 in _ih_sub_add (sub=sub@entry=0x82d5d38) at /build/buildd/glib2.0-2.39.92/./gio/inotify/inotify-helper.c:109
#2 0xb7db29ed in g_inotify_directory_monitor_start (local_monitor=0x828b038)
    at /build/buildd/glib2.0-2.39.92/./gio/inotify/ginotifydirectorymonitor.c:90
#3 0xb7da2f00 in g_local_directory_monitor_start (local_monitor=0x828b038)
    at /build/buildd/glib2.0-2.39.92/./gio/glocaldirectorymonitor.c:119
#4 0xb7d41acc in desktop_file_dir_init (dir=0x82a20c4) at /build/buildd/glib2.0-2.39.92/./gio/gdesktopappinfo.c:847
#5 desktop_file_dirs_lock () at /build/buildd/glib2.0-2.39.92/./gio/gdesktopappinfo.c:939
#6 0xb7d43c9f in desktop_file_dirs_refresh () at /build/buildd/glib2.0-2.39.92/./gio/gdesktopappinfo.c:951
#7 mime_info_cache_init_dir_lists () at /build/buildd/glib2.0-2.39.92/./gio/gdesktopappinfo.c:4086
#8 mime_info_cache_init () at /build/buildd/glib2.0-2.39.92/./gio/gdesktopappinfo.c:4130
#9 get_all_desktop_entries_for_mime_type (base_mime_type=base_mime_type@entry=0x82306c7 "text/calendar",
    include_fallback=include_fallback@entry=1, explicit_default=explicit_default@entry=0xbfffe96c, except=0x0)
    at /build/buildd/glib2.0-2.39.92/./gio/gdesktopappinfo.c:4234
#10 0xb7d45ad9 in g_app_info_get_all_for_type (content_type=0x82306c7 "text/calendar")
    at /build/buildd/glib2.0-2.39.92/./gio/gdesktopappinfo.c:3363

...meaning that, once indicator-datetime makes the mistake of calling g_app_info_get_all_for_type(), glib will keep polling "/usr/share/ubuntu/applications" and "/usr/local/share/applications" every four seconds forever, even though the app doesn't use that mime information again. :/

With a call to g_app_info_get_all_for_type():

> Wakeups:
> PID Process Wake/Sec Kernel Functions
> 8242 indicator-datetime-s 0.25 (schedule_hrtimeout_range_clock, hrtimer_wakeup) (very low)
> 8237 indicator-datetime-s 0.02 (schedule_hrtimeout_range_clock, hrtimer_wakeup) (very low)
> Total 0.27

Without the call:

> Wakeups:
> PID Process Wake/Sec Kernel Functions
> 16939 indicator-datetime-s 0.02 (schedule_hrtimeout_range_clock, hrtimer_wakeup) (very low)

Adding Ryan for a second opinion since he's got his name as co-Author on gdesktopappinfo.c ;-)

This is my fault indeed. I introduced the code that added this watch without remembering that it does the wrong thing in the case of missing directories. I think the correct fix here is to reevaluate our approach to dealing with missing files in the inotify monitor...

This bug was fixed in the package indicator-datetime - 13.10.0+14.04.20140328-0ubuntu1

---------------
indicator-datetime (13.10.0+14.04.20140328-0ubuntu1) trusty; urgency=low

  [ Charles Kerr ]
  * Short-term workaround for the GIO GAppInfo wakeup bug discussed in
    bug 1296233 (LP: #1296233)
  * Improved translator comments for better time/date localization. (LP:
    #1001595)
 -- Ubuntu daily release <email address hidden> Fri, 28 Mar 2014 16:11:23 +0000

Any update on fixing GIO? Maybe we can already revert this hack?