Bug 629872 - imsettings sometimes failed to run ibus
imsettings sometimes failed to run ibus
Status: CLOSED WORKSFORME
Product: Fedora
Classification: Fedora
Component: imsettings (Show other bugs)
13
All Linux
low Severity medium
: ---
: ---
Assigned To: Akira TAGOH
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-09-03 03:29 EDT by fujiwara
Modified: 2010-12-09 02:55 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-12-09 02:55:51 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description fujiwara 2010-09-03 03:29:23 EDT
It seems imsettings sometimes failed to run ibus-daemon with timeout when I change the login languages (maybe user-dirs-update-gtk effects).
Having a timeout option for imsettings-start might be good.
The default timeout would be 2.5 sec.

The test case works good with me:
--- imsettings-0.108.1/imsettings/imsettings-request.c.orig
+++ imsettings-0.108.1/imsettings/imsettings-request.c
@@ -29,6 +29,11 @@
 #include <glib/gi18n-lib.h>
 #include <dbus/dbus-glib-lowlevel.h>
 #include <dbus/dbus-glib-bindings.h>
+
+#ifdef HAVE_LOCALE_H
+#include <locale.h>
+#endif
+
 #include "imsettings-request.h"
 #include "imsettings.h"
 #include "imsettings-utils.h"
@@ -236,10 +241,19 @@ imsettings_request_get_version(IMSetting
 	g_return_val_if_fail (IMSETTINGS_IS_REQUEST (imsettings), 0);
 
 	priv = IMSETTINGS_REQUEST_GET_PRIVATE (imsettings);
+#if 0
 	if (!dbus_g_proxy_call(priv->proxy, "GetVersion", &err,
 			       G_TYPE_INVALID,
 			       G_TYPE_UINT, &retval,
 			       G_TYPE_INVALID))
+#else
+	if (!dbus_g_proxy_call_with_timeout (priv->proxy, "GetVersion",
+                                             60000,
+                                             &err,
+			                     G_TYPE_INVALID,
+			                     G_TYPE_UINT, &retval,
+			                     G_TYPE_INVALID))
+#endif
 		g_warning(_("Failed to invoke a method `%s' on %s:\n  %s"),
 			  "GetVersion",
 			  dbus_g_proxy_get_interface(priv->proxy),
@@ -317,7 +331,11 @@ imsettings_request_get_info_object(IMSet
 	IMSettingsInfo *retval = NULL;
 	GValueArray *ret = NULL;
 	GError *err = NULL;
+#ifdef HAVE_LOCALE_H
 	const gchar *locale = setlocale(LC_CTYPE, NULL);
+#else
+	const gchar *locale = NULL;
+#endif
 
 	g_return_val_if_fail (IMSETTINGS_IS_REQUEST (imsettings), NULL);
Comment 1 fujiwara 2010-09-03 03:36:49 EDT
The GError of dbus_g_proxy_call() via imsettings_request_get_version():

{domain = 73, code = 4, message = 
    0x927990 "Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection w"...}
Comment 2 fujiwara 2010-09-03 03:49:54 EDT
(In reply to comment #0)
> The default timeout would be 2.5 sec.

s/2.5 sec/25 sec/
Comment 3 Akira TAGOH 2010-09-15 00:34:24 EDT
How to reproduce this? since it relies on DBus on the request and the response, I'm just wondering if other DBus services also works without any problems.
Comment 4 fujiwara 2010-12-09 02:55:51 EST
To speak strictly, this bug needed the fix of bug 530711 for me.
The original patch updates the gconf value when the language is changed and it causes the performance of ibus-daemon and the this timeout problem is happened.

But after I discussed the patch with upstream, we agreed not to update gconf if the preload list is the language base. So probably I won't encounter this problem.

Closing this at the moment.

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