| Summary: | failure to register before timeout | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | Guillaume Rousse <guillomovitch> |
| Component: | RPM Packages | Assignee: | Mageia Bug Squad <bugsquad> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | Normal | CC: | mageia, olav |
| Version: | Cauldron | Keywords: | UPSTREAM |
| Target Milestone: | --- | ||
| Hardware: | i586 | ||
| OS: | Linux | ||
| URL: | https://bugzilla.gnome.org/show_bug.cgi?id=677081 | ||
| Whiteboard: | |||
| Source RPM: | gnome-settings-daemon | CVE: | |
| Status comment: | |||
|
Description
Guillaume Rousse
2012-02-26 22:12:31 CET
I also find one of the error signaled in bug #4667: Avertissement du gestionnaire de fenêtres : Log level 16: Unable to register authentication agent: GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: An authentication agent already exists for the given subject I'm using systemd, BTW. Hmmm.... I think I remember this bug from a while ago with e.g. gdm. The failed to register thing is basically caused by a missing build dep... lemme take a look. CC:
(none) =>
mageia Scratch that. I thought it was maybe missing a libsm require, but I don't see any linkage against it, optional or otherwise in the code. I guess it's just a consolekit vs. systemd user session thing? I didn't enable any systemd things. Perhaps we need to explicitly disable it to be really sure it doesn't get enabled by accident? Bit late today, I want to see if I can reproduce locally. Starting a session is ok, big problem is the memory usage of mutter/gnome-shell (eventually using 1.2GB). CC:
(none) =>
olav FWIW, things seem to work OK for me too. I can even see gnome-settings-daemon listed in dbus introspection of org.gnome.SessionManager (I have it as Client 4). What does systemctl status console-kit-daemon.service say? (I see the g-s memory hog bug too - urk!) OK, I found the issue by comparing warnings in ~/.xsession-errors with a new user (which had no problems): I was missing at-spi2-atk package. I don't know how it was uninstalled, and it's also quite painful than missing an optional accessibility stuff leads to such problems. Status:
NEW =>
RESOLVED Strange. I do not have that package installed here either... will keep my eyes open at the next reboot! Maybe at-spi2-atk is a suggests and it should be a require? If it happens to you, might happen to others. Checking, it seems I do not have it installed (bit weird). Just did a reboot. Can't say I'm missing the at-spi2-atk package. Everything seems fine without it.... I do get the same error you noticed: Window manager warning: Log level 16: Unable to register authentication agent: GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: An authentication agent already exists for the given subject Window manager warning: Log level 16: Error registering polkit authentication agent: GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: An authentication agent already exists for the given subject (polkit-error-quark 0) But it seems harmless enough... :s Unfortunatly, the issue is back, with a more frightening error messages: ** CRITICAL **: DBus AddMatch for dconf path '/org/gnome/settings-daemon/plugins/housekeeping/': La connexion est fermée GLib-GIO-CRITICAL **: g_dbus_connection_signal_subscribe: assertion `G_IS_DBUS_CONNECTION (connection)' failed ** WARNING **: Could not connect: Connexion refusée GLib-GIO-CRITICAL **: Error while sending AddMatch() message: La connexion est fermée g_dbus_connection_real_closed: Remote peer vanished with error: Underlying GIOStream returned 0 bytes on an async read (g-io-error-quark, 0). Exiting. Status:
RESOLVED =>
REOPENED And I don't have any issues (aside from gdm not starting in the proper mode). And the culprit is... cups trying to contact the cups server declared in ~/.cups/client.conf. If the network is not available, or if there is no such server declared, everything is OK. The problem still exists... Could you file a bug upstream maybe? This is a bit too detailed for me.. To reproduce would all I need to do is put some invalid data in ~/.cups/client.conf? colin: in theory, yes. Hi, This bug was filed against cauldron, but we do not have cauldron at the moment. Please report whether this bug is still valid for Mageia 2. Thanks :) Cheers, marja Keywords:
(none) =>
NEEDINFO Bug reported upstream: https://bugzilla.gnome.org/show_bug.cgi?id=677081 Keywords:
NEEDINFO =>
UPSTREAM This was fixed upstream, closing. Status:
REOPENED =>
RESOLVED |