Bug 853036 - abrt-applet slows down login by trying to access notification daemon
Summary: abrt-applet slows down login by trying to access notification daemon
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: abrt
Version: 17
Hardware: x86_64
OS: Unspecified
medium
medium
Target Milestone: ---
Assignee: Jakub Filak
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-08-30 10:24 UTC by Milan Bouchet-Valat
Modified: 2016-12-01 00:42 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-06-28 17:59:42 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Milan Bouchet-Valat 2012-08-30 10:24:03 UTC
For some time my session hangs for minutes at login. Today I discovered it's because of abrt-applet, which seems to be trying to connect to notification daemon over D-Bus. Here's the excerpt from ~/.xsession-errors before I killed abrt-applet:
(abrt:1472): libnotify-WARNING **: Failed to connect to proxy
abrt-applet: Failed to receive server caps

(abrt:1472): libnotify-WARNING **: Failed to connect to proxy
abrt-applet: Failed to receive server caps

(abrt:1472): libnotify-WARNING **: Failed to connect to proxy
abrt-applet: Failed to receive server caps
abrt-applet: GDBus.Error:org.freedesktop.DBus.Error.UnknownMethod: L'interface « org.freedesktop.Notifications » n'existe pas pour l'objet à l'emplacement /org/freedesktop/Notifications

This sequence is repeated about 5 times in a few seconds. This really looks like a race condition where GNOME Shell is not ready yet, and abrt-applet immediately tries to contact it over D-Bus (if a crash report is found, probably). I'm not able to reproduce this all the time, but this is quite frequent.

Maybe abrt-applet should find a better way of handling notifications at startup? It could probably watch the bus and only act when a process claims org.freedesktop.Notifications. Or is this a problem with gnome-shell and gnome-session, because the latter should not start applications until the former is ready?

Comment 1 Milan Bouchet-Valat 2012-08-30 11:59:27 UTC
I've noticed at least one problem in src/applet/applet.c: the return value from notify_init() (boolean) is not used at all. This means if notify_init() fails (which is the case here), notify_get_server_caps() is called anyway, which triggers the "Failed to receive server caps" error. Maybe this triggers delays, though I'm not sure why.

static void call_notify_init(void)
{
    static bool inited = 0;
    if (inited)
        return;
    inited = 1;

    notify_init(_("Problem detected"));
}

#if !defined(NOTIFY_VERSION_MINOR) || (NOTIFY_VERSION_MAJOR == 0 && NOTIFY_VERSION_MINOR >= 6)
static gboolean server_has_persistence(void)
{
    GList *caps;
    GList *l;

    call_notify_init();

    caps = notify_get_server_caps();
    if (caps == NULL)
    {
        error_msg("Failed to receive server caps");
        return FALSE;
    }

    l = g_list_find_custom(caps, "persistence", (GCompareFunc)strcmp);

    list_free_with_free(caps);
    VERB1 log("notify server %s support pesistence", l ? "DOES" : "DOESN'T");
    return (l != NULL);
}
#else
# define server_has_persistence() call_notify_init()
#endif


Below, in main(), there's another call to init_applet() in a loop over new crash directories. This function returns void, and after that show_problem_notification() is called, disregarding whether notify_init() succeeded or not. This may well be the call triggering the second error:
abrt-applet: GDBus.Error:org.freedesktop.DBus.Error.UnknownMethod: Interface « org.freedesktop.Notifications » does not exist for object at path /org/freedesktop/Notifications

Even if that's not the cause of my problems at login, these oddities deserve fixes!

Comment 2 Jakub Filak 2013-06-28 11:49:54 UTC
The mentioned code was rewritten in:

commit 327e52cd20a877afe3654c8aa5956651c9d959e6
Author: Jakub Filak <jfilak>
Date:   Tue Dec 4 13:53:59 2012 +0100

    introduce Desktop Session Autoreporting
    
    - closes trac#763, trac#768
    
    Signed-off-by: Jakub Filak <jfilak>



Do you still experience this problem?

Comment 3 Milan Bouchet-Valat 2013-06-28 17:59:42 UTC
From a code inspection, indeed the problem seems to be gone. I have not experienced it for a while anyway so I cannot confirm.


Note You need to log in before you can comment on or make changes to this bug.