Bug 1472607 - ibus randomly doesn't initialize properly, reqires relogin [NEEDINFO]
ibus randomly doesn't initialize properly, reqires relogin
Status: NEW
Product: Fedora
Classification: Fedora
Component: ibus (Show other bugs)
25
x86_64 Unspecified
unspecified Severity medium
: ---
: ---
Assigned To: fujiwara
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2017-07-19 02:03 EDT by Alexander Gavrilov
Modified: 2017-07-31 00:26 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
tfujiwar: needinfo? (angavrilov)


Attachments (Terms of Use)
Process list in a failure state (24.67 KB, text/plain)
2017-07-19 02:03 EDT, Alexander Gavrilov
no flags Details
Process list after relogin (24.43 KB, text/plain)
2017-07-19 02:03 EDT, Alexander Gavrilov
no flags Details
imsettings-info (doesn't change after relogin) (321 bytes, text/plain)
2017-07-19 02:04 EDT, Alexander Gavrilov
no flags Details
/proc/<ibus-daemon>/environs (doesn't change either) (555 bytes, application/x-shellscript)
2017-07-19 02:05 EDT, Alexander Gavrilov
no flags Details
.cache/imsettings/log.bak (should be from the failed session) (4.19 KB, text/plain)
2017-07-19 03:18 EDT, Alexander Gavrilov
no flags Details
various logs (35.82 KB, application/zip)
2017-07-24 02:16 EDT, Alexander Gavrilov
no flags Details
custom keyboard layout (702 bytes, patch)
2017-07-24 02:21 EDT, Alexander Gavrilov
no flags Details | Diff
.cache/imsettings/log with verbose after 'ibus restart' (7.11 KB, text/plain)
2017-07-31 00:17 EDT, Alexander Gavrilov
no flags Details

  None (edit)
Description Alexander Gavrilov 2017-07-19 02:03:02 EDT
Created attachment 1300821 [details]
Process list in a failure state

Description of problem:

Ever since upgrading to Fedora 23 I've had a problem where ibus quite often won't initialize properly on first login after reboot, and this continues after upgrade to Fedora 25.

Version-Release number of selected component (if applicable):

ibus-1.5.14-5.fc25.x86_64
kdelibs-4.14.30-2.fc25.x86_64

How reproducible:

Random but frequent.

Steps to Reproduce:

1. Boot the system
2. Log in to KDE

Actual results:

Some ibus processes are running, but there is no tray icon and it doesn't work. This is fixed by logout and login.

Additional info:

I'm a programmer and could try debugging this myself to fix or provide more info, but I have no idea where to start since this happens during startup and feels like some kind of race condition in initialization due to lots of programs trying to start at the same time.
Comment 1 Alexander Gavrilov 2017-07-19 02:03 EDT
Created attachment 1300822 [details]
Process list after relogin
Comment 2 Alexander Gavrilov 2017-07-19 02:04 EDT
Created attachment 1300824 [details]
imsettings-info (doesn't change after relogin)
Comment 3 Alexander Gavrilov 2017-07-19 02:05 EDT
Created attachment 1300825 [details]
/proc/<ibus-daemon>/environs (doesn't change either)
Comment 4 fujiwara 2017-07-19 02:52:11 EDT
(In reply to Alexander Gavrilov from comment #0)
> Some ibus processes are running, but there is no tray icon and it doesn't
> work. This is fixed by logout and login.

Do you mean your problem is only that ibus panel icon does not show but ibus IME works fine, e.g. Super+space, ibus-setup?

Does `ibus restart` command work for you to fix your problem?

Can you attach a screenshot of your desktop on this bug report?

> I'm a programmer and could try debugging this myself to fix or provide more
> info, but I have no idea where to start since this happens during startup

The panel icon is handled by ibus-ui-gtk3 and Fedora srpm is available.


(In reply to Alexander Gavrilov from comment #2)
> Created attachment 1300824 [details]
> imsettings-info (doesn't change after relogin)

Can you check $HOME/.cache/imsettings/log ?
Comment 5 Alexander Gavrilov 2017-07-19 03:18 EDT
Created attachment 1300880 [details]
.cache/imsettings/log.bak (should be from the failed session)
Comment 6 Alexander Gavrilov 2017-07-19 03:21:35 EDT
The keyboard layout is set to xkb default qwerty instead of dvorak configured via ibus, and switch keys don't work. In the process list, ibus-engine-simple isn't running too.

I'll try the commands when this happens again.
Comment 7 fujiwara 2017-07-19 04:46:00 EDT
If ibus-engine-simple is not running, ibus-ui-gtk3 shows a keyboard icon instead of a string icon or no icon. You described no icon but ibus-ui-gtk3 was living from your process list. 
I wonder if your ibus-daemon restarted when you saw your problem.
Comment 8 fujiwara 2017-07-19 04:48:58 EDT
(In reply to Alexander Gavrilov from comment #0)
> kdelibs-4.14.30-2.fc25.x86_64

This is a wrong pointer. KDE is now Plasma (version 5).

# rpm -qf /usr/lib64/qt5/plugins/platforminputcontexts/libibusplatforminputcontextplugin.so 
qt5-qtbase-gui-5.7.1-10.fc25.x86_64
Comment 9 Alexander Gavrilov 2017-07-19 12:48:05 EDT
$ rpm -qf /usr/lib64/qt5/plugins/platforminputcontexts/libibusplatforminputcontextplugin.so 
qt5-qtbase-gui-5.7.1-16.fc25.x86_64

No icon means no icon present in the tray, so maybe it fails to connect to whatever manages the tray in kde for some reason.

I think I tried killing and restarting ibus-ui-gtk3 manually once, and it restored the icon but was still broken in some way I don't recall (maybe the hotkey still didn't work).
Comment 10 fujiwara 2017-07-19 22:58:27 EDT
(In reply to Alexander Gavrilov from comment #9)
> I think I tried killing and restarting ibus-ui-gtk3 manually once, and it
> restored the icon but was still broken in some way I don't recall (maybe the
> hotkey still didn't work).

OK, I need to know the reproducing steps exactly.
Seems you cannot reproduce your problem now.
Comment 11 Alexander Gavrilov 2017-07-20 12:50:22 EDT
As I said, reproducing steps are very simple:

1. Boot up the system from power off
2. Log into KDE
3. Randomly (feels like maybe 1/3 probability), ibus isn't working.
4. Logout and second login fixes it.

Doing a full reboot is a rather annoying thing to have do repeatedly to reproduce it on purpose, so I'm just waiting for it to happen naturally again. I wonder though, if just clearing all in-memory disk caches before re-login could be sufficient to trigger it, in case this is indeed a race condition caused by stuff loading slowly from disk...
Comment 12 Alexander Gavrilov 2017-07-20 13:08:18 EDT
Under the race condition theory the following things may be also necessary to reproduce:

1. Use ordinary HDD instead of fancy SSDs.
2. Have your session configured to auto-start a number of heavy apps like kmail, skype, firefox with 50 open tabs, so that everything is heavily IO bottlenecked and slow to load.
Comment 13 fujiwara 2017-07-21 00:14:22 EDT
(In reply to Alexander Gavrilov from comment #11)
> 3. Randomly (feels like maybe 1/3 probability), ibus isn't working.

I think this is still too fuzzy to evaluate this issue.

How often did you reproduce your problem?

Probably it's good to run ibus-daemon with verbose whenever you login.

% ibus exit
% ibus-daemon --xim --verbose >& your.log

> Doing a full reboot is a rather annoying thing to have do repeatedly to
> reproduce it on purpose, so I'm just waiting for it to happen naturally
> again. I wonder though, if just clearing all in-memory disk caches before

If you have a good reproducing steps and I can do it, I can evaluate it.
If you sometimes reproduce your issue, I will ask you to run some debug programs to find a root cause.

> re-login could be sufficient to trigger it, in case this is indeed a race
> condition caused by stuff loading slowly from disk...

Did you really debugged ibus?
You also didn't explain which is race in the source codes.

I wonder if your problem is caused by a hardware issue.
It might be good to check disk S.M.A.R.T.
Comment 14 Alexander Gavrilov 2017-07-21 12:59:10 EDT
So, the bug happened again, and here are the results:

Initially: there is no ibus icon in the tray, keyboard layout is wrong, hotkey doesn't work, ibus-setup pops up the window.

Killing and manually starting ibus-ui-gtk3 shows up the icon, but hotkey still doesn't work. Trying to switch layouts by clicking on the icon doesn't really work either, probably because I have it configured so that every app has separate selected layout, and clicking on the icon switches focus to the tray temporarily so it doesn't change the layout of the really active app.

Using 'ibus restart' seems to fix the problem: layouts are right, hotkeys work. Switching via icon still broken for stated reasons.

So I guess 'ibus restart' is better than relogin, but the question is what breaks it in the first place.


Re race condition, it is just a guess as it's a likely cause of a heisenbug appearing under high load conditions; and I imagine it as a race between different interdependent components of ibus and kde trying to start up at the same time, possibly even in different processes. I actually see app windows appear on the screen before the panel with the icon tray shows up and pushes them aside, so the whole thing obviously isn't starting up in completely orderly fashion.
Comment 15 fujiwara 2017-07-24 02:07:31 EDT
(In reply to Alexander Gavrilov from comment #14)
> Initially: there is no ibus icon in the tray, keyboard layout is wrong,
> hotkey doesn't work, ibus-setup pops up the window.

You didn't attach a log file as I noted in comment 13.

Also I wonder attachment 1300880 [details] is not correct.
I also need the $HOME/.cache/imsettings/log before you restart ibus.

> Killing and manually starting ibus-ui-gtk3 shows up the icon, but hotkey
> still doesn't work. Trying to switch layouts by clicking on the icon doesn't
> really work either, probably because I have it configured so that every app
> has separate selected layout, and clicking on the icon switches focus to the
> tray temporarily so it doesn't change the layout of the really active app.

OK.

> but the question is what breaks it in the first place.

Probably it's my question to you since you didn't give the exact info.

As I just remember now, probably you configure keyboard settings with KDE instead of IBus.

Can you confirm to run systemsettings5 ?
"System Settings" -> "Hardware" -> "Input Devices" -> "Keyboard" -> "Layouts"
And disable "Configure layouts".

> Re race condition, it is just a guess as it's a likely cause of a heisenbug
> appearing under high load conditions; and I imagine it as a race between
> different interdependent components of ibus and kde trying to start up at
> the same time, possibly even in different processes. I actually see app
> windows appear on the screen before the panel with the icon tray shows up
> and pushes them aside, so the whole thing obviously isn't starting up in
> completely orderly fashion.

Maybe it's not true.
Comment 16 Alexander Gavrilov 2017-07-24 02:16 EDT
Created attachment 1303457 [details]
various logs
Comment 17 Alexander Gavrilov 2017-07-24 02:21 EDT
Created attachment 1303459 [details]
custom keyboard layout
Comment 18 Alexander Gavrilov 2017-07-24 02:28:44 EDT
Given that the problem happens when the session initially starts up, and ibus restart fixes it, it seems that in order to get a useful log it's necessary to somehow make ibus-daemon start in such verbose logging mode by default (maybe I can edit some script or such?).

I don't use configure layouts, only configure keyboard options to enable menu key to switch layout. However I use a patched simple.xml (I've been doing that since 2014 so it can't be related to this problem) to add a special layout to use as my primary. Basically my ibus layout set is:

1. custom dvorak+russian (switch using xkb menu key) - primary
2. qwerty - for games and other apps with hotkeys designed for it
3. ibus-anthy

This all worked perfectly until I upgraded to Fedora 23, and now 25. Btw, ibus-anthy kana input seems totally broken in 25 too somehow, but I haven't looked into that at all yet; I've been tweaking and patching it to work properly for years anyway.
Comment 19 fujiwara 2017-07-24 04:56:54 EDT
(In reply to fujiwara from comment #15)
> (In reply to Alexander Gavrilov from comment #14)
> > Initially: there is no ibus icon in the tray, keyboard layout is wrong,
> > hotkey doesn't work, ibus-setup pops up the window.
> 
> You didn't attach a log file as I noted in comment 13.

Why don't you attach the log as I noted in comment 13 ?

(In reply to fujiwara from comment #13)
> % ibus-daemon --xim --verbose >& your.log

I mean the ibus-daemon kicked by imsettings saves that log.
This might include any warnings when you get your issue.

Also I wonder why you always got m17n info in your imsettings log. The info should be saved in one time when you run ibus-daemon after you install ibus-m17n.

(In reply to Alexander Gavrilov from comment #17)
> Created attachment 1303459 [details]
> custom keyboard layout

I found one problem.
Current ibus uses two language prefix instead of three language prefix to use "CS" instead of "CZ" for cze language and your patch causes a SEGV.

Please replace rus with ru:

- <language>rus</language>
+ <language>ru</language>
Comment 20 Alexander Gavrilov 2017-07-24 05:16:08 EDT
(In reply to fujiwara from comment #19)
> Why don't you attach the log as I noted in comment 13 ?
> 
> I mean the ibus-daemon kicked by imsettings saves that log.
> This might include any warnings when you get your issue.

I'll try to make one next time it happens.
 
> Also I wonder why you always got m17n info in your imsettings log. The info
> should be saved in one time when you run ibus-daemon after you install
> ibus-m17n.

No idea. One thing is that I have been upgrading my system for years without full reinstall, so there potentially might be some stale configuration somewhere confusing things.
 
> - <language>rus</language>
> + <language>ru</language>

done
Comment 21 fujiwara 2017-07-25 04:55:09 EDT
(In reply to Alexander Gavrilov from comment #20)
> (In reply to fujiwara from comment #19)
> > Why don't you attach the log as I noted in comment 13 ?
> > 
> > I mean the ibus-daemon kicked by imsettings saves that log.
> > This might include any warnings when you get your issue.
> 
> I'll try to make one next time it happens.

FYI:
% cp /etc/X11/xinit/xinput.d/ibus.conf $HOME/.config/imsettings/xinputrc
% vi $HOME/.config/imsettings/xinputrc
XIM_ARGS="-r --xim --verbose"

And then imsettings log will save the ibus verbose log.

> > Also I wonder why you always got m17n info in your imsettings log. The info
> > should be saved in one time when you run ibus-daemon after you install
> > ibus-m17n.
> 
> No idea. One thing is that I have been upgrading my system for years without
> full reinstall, so there potentially might be some stale configuration
> somewhere confusing things.

I mean your ibus component files might be broken or you have no permission in cache dir and should be reviewed.
Comment 22 Alexander Gavrilov 2017-07-31 00:17 EDT
Created attachment 1306779 [details]
.cache/imsettings/log with verbose after 'ibus restart'

After adding verbose the log doesn't seem to be much different. However after the problem happened again and I ran ibus restart, a few possibly interesting lines appeared at the end.
Comment 23 fujiwara 2017-07-31 00:26:31 EDT
I don't ask to restart ibus.

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