Description of problem:
after Each login, there is error (or just) message that "Unable to keep Input Method Running" (and more detail). But IBus was working Normal after this message.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. login to local language desktop
2. you will get message if not please follow
3. System->Preferences -> Input Method
4. There was nothing Selected
5. Try to Enable Input Method
message will be there on Right Top Corner
Default Should be enabled as Ibus was working or no such message
Created attachment 362432 [details]
Attaching .imsettings.log File
which version of imsettings are you using?
Can you have the real steps to reproduce this issue? as the log file you've attached at Comment #1 said, this message appears because ibus-daemon is already running. in other words, the key point is how you can see ibus-daemon running after even logged out.
FWIW there were a bug that imsettings couldn't terminate it properly in the older version. so if you've tried on rawhide box live-updated from the older imsettings, this issue may occurs. and there are no way of preventing it unfortunately.
Otherwise please give me more info how to reproduce that.
ok, it was upgrade, also produced when upgrade from Fedora 10 to Fedora 11.
Steps are same, as I login each time, it shows same message, but only with
upgrade (fedora 10 to fedora 11 or fedora 11 ->rawhide).
Please close bug as you find more relevant type (to close)
Okay. please make sure you don't see this issue after killing ibus-daemon manually or just reboot your machine. if you still see, please reopen this.
Sorry, but it is appearing with each login (even after restart also)
Sure. please check if:
1. you're sure no ibus-daemon is running at first.
2. ibus-daemon is running once you log into the desktop and log out. you can see that from the console say. press alt+ctrl+Fn on gdm to switch VT.
then attach .imsettings.log again _before_ logging into the desktop again. also describe what you did during the desktop session is alive.
Created attachment 362635 [details]
after reboot machine, I login once, did Nothing (message was there),
just logout. copy .imsettings.log file from VT without GUI login.
Let me know if any step was wrong to redo.
Did you see that message with even the first login after rebooting? hmm, then please check if ibus-daemon is running after rebooting. if it's there, who's the parent of its process?
(In reply to comment #9)
> after reboot machine, I login once, did Nothing (message was there),
> just logout. copy .imsettings.log file from VT without GUI login.
To clarify more, what kind of the message did you see?
Created attachment 364061 [details]
Error Screenshot for iBus
"Unable to keep Input Method Running..."
Screenshot is not very clear, but message is like that
Aha. didn't you reboot your machine before this testing? then please read comment #10. I'm not quite sure where that process was being brought up from.
Any further information are welcome too. at least it works for me on GNOME desktop with the users newly created.
The same problem happens in my linux.
locale : ko_KR.UTF-8
$ cat .xinputrc
if test -f /usr/lib/qt4/plugins/inputmethods/libqtim-ibus.so || \
test -f /usr/lib64/qt4/plugins/inputmethods/libqtim-ibus.so;
Can anyone give me the useful information as I told at comment #10?
Created attachment 366544 [details]
parent process graph for ibus
Thanks. I guess you've enabled a kind of the self-running feature with XDG's autostart before. you may have ibus.desktop or something like that in $HOME/.config/autostart ?
After the talk with Alam on IRC, my guess is correct. since we don't use this feature in Fedora at least, it may be a good idea to get rid of that file automatically if available. reassigning to ibus for that.
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle.
Changing version to '12'.
More information and reason for this action is here:
I have removed auto start feature in current ibus. Probably this file was created by early version. Please remove it by self. Thanks.
Right. but it's not that reasonable to remove by the hand since this causes not working ibus. I don't know how many people used that feature though, the fix in ibus should be easier than the cost of the problem.
Plus, any version of ibus doesn't provide any solutions for *this* issue since the bug reporter complains ibus.desktop introduced the issue ibus not running. so closing as CURRENTRELEASE is wrong at least.
Actually, this feature has been removed for a long time (Only 0.1.x has this feature). 1.1.x and 1.2.x do not have it. I think it is not necessary to remove it automatically. If really need it, I suggest do it in xinit script (For exmaple /etc/X11/xinit/xinitrc.d/50-xinput.sh). ibus can not remove it before X init scripts.
If you agree, I will move this bug to imsettings, and we fix it in /etc/X11/xinit/xinitrc.d/50-xinput.sh, or I will close it as wontfix.
(In reply to comment #22)
> Hi Tagoh-san,
> Actually, this feature has been removed for a long time (Only 0.1.x has this
> feature). 1.1.x and 1.2.x do not have it. I think it is not necessary to remove
> it automatically. If really need it, I suggest do it in xinit script (For
> exmaple /etc/X11/xinit/xinitrc.d/50-xinput.sh). ibus can not remove it before X
> init scripts.
ibus isn't brought up before xinit script right. there are no reasons ibus can't remove it.
The problem is, two ibus instance is going to run. and ibus.desktop is prior to imsettings'. so you can do change the logic in ibus like if there are ibus.desktop under $HOME/.config/autostart, remove it and just exit. this would resolves this issue and imsettings successfully can brings up ibus then.
I still think it is not good to do it in ibus.
Users also have right to use gnome-sesstion-properties to create it by self. So I will close it as wontfix. Thanks.