Bug 1472607
| Summary: | ibus randomly doesn't initialize properly, reqires relogin | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Alexander Gavrilov <angavrilov> |
| Component: | ibus | Assignee: | fujiwara <tfujiwar> |
| Status: | CLOSED EOL | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 25 | CC: | angavrilov, i18n-bugs, shawn.p.huang, smaitra, tfujiwar |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2017-12-12 10:21:32 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Attachments: | |||
Created attachment 1300822 [details]
Process list after relogin
Created attachment 1300824 [details]
imsettings-info (doesn't change after relogin)
Created attachment 1300825 [details]
/proc/<ibus-daemon>/environs (doesn't change either)
(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 ? Created attachment 1300880 [details]
.cache/imsettings/log.bak (should be from the failed session)
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. 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. (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 $ 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). (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. 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... 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. (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. 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. (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. Created attachment 1303457 [details]
various logs
Created attachment 1303459 [details]
custom keyboard layout
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. (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> (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 (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. 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.
I don't ask to restart ibus. This message is a reminder that Fedora 25 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 25. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '25'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 25 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. Probably I think this is fixed in ibus-1.5.17-1 which is available in f26 or later. Fedora 25 changed to end-of-life (EOL) status on 2017-12-12. Fedora 25 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed. Finally got around to updating to 27 a week ago and it seems it's indeed fixed. |
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.