After using my computer for some time, X11 will stop reacting to some mouse clicks. The first symptom that presents is much like https://bugzilla.redhat.com/show_bug.cgi?id=1027524 where I must use Alt+Tab to switch applications. Wthin an app mouse clicks appear to work well. I can get everything work partially for a while by moving to a different virtual desktop (alt+control+right/left and back. After some time that stops working and no mouse clicks are acknowledged anywhere. Note that Alt+Tab always seems to work and that, as far as I can tell, keyboard input always seems to work. I see nothing in /var/log/messages (or journalctl) or /var/log/Xorg.0.log that seems problematic. The symptoms I see are different from https://bugzilla.redhat.com/show_bug.cgi?id=1043048 and https://bugzilla.redhat.com/show_bug.cgi?id=1043049 in that my keyboard input always seems to work. The time to reproduce this varies. It has happened within seconds of launching chrome/firefox on first boot. I've also seen this after almost a full day of work before the first symptom appears. Since I use openbox, the quickest way for me to get back to a working state is to run: openbox --replace and relaunch all my applications. So far this has always restored my system to working as expected.
Unlike https://bugzilla.redhat.com/show_bug.cgi?id=984333, I do not run virt-manager or vnc-server or nomachine or other remote desktop app on this machine.
Is there anything I can look at that will give me some clue about this problem? I didn't see these symptoms at all yesterday. Today I saw them right away.
Hi, (In reply to John Schmitt from comment #0) <snip> > Since I use openbox, the quickest way for me to get back to a working state > is to run: > > openbox --replace So you do not restart the X-server, only replace the window manager ? > and relaunch all my applications. So far this has always restored my system > to working as expected. Why do you need to relaunch your applications, don't those keep running when you do an openbox --replace ? If you can get around this without restarting the xserver it is likely not a xserver bug. One thing which may cause the behavior you're describing is an application grabbing the mouse and never releasing it. You could do a "ps aux" and check for somebackground apps you don't use, and try killing them. You could also try killing all your apps one by one until the problem goes away. Assuming this leads to you finding a culprit app, you should file a new bug with a summary of "app foo grabs the mouse and never releases it", and mark this bug as a duplicate of the new bug. Regards, Hans
Regarding re-launching my apps, I assumed they were being relaunched by my session. I didn't realise they might be the same instances. I will try your suggestions as soon as these symptoms present, thank you.
I tried to follow your advice. I used htop to send a SIGQUIT to anything that would listen until I had only konsole and LightDM still running. I saw no improvement in behaviour from it. When I gave up and resorted to restarting openbox, I received an error message. $ openbox --replace XIO: fatal IO error 11 (Resource temporarily unavailable) on X server ":0" after 396 requests (396 known processed) with 2 events remaining. I have to relaunch my applications because openbox --replace has the effect of logging me back to the LightDM greeter.
Hi John, Do you always get thrown back to the lightdm login screen when you try to do a "openbox --replace" or did this only happen after you killed all other apps first? Regards, Hans
Hi Hans. As far as I can recall, typing "openbox --replace" at the console has always brought me to the lightdm login screen in Fedora 20. For Fedora 18, I do not recall. I tried compiz with Fedora 17/18 a long time ago. My recollection is that it did not bring me back to the login screen back then.
Hi Again, Ok, this may be due openbox being the session leader, so replacing it causes the Xserver to exit because it looses the connection from the main app. Can you try doing from a terminal, in your home-dir: sudo yum install xterm echo "exec xterm" > .xinitrc Then logout of openbox, and at the lightdm screen, switch to vt2 (use ctrl + alt + f2) and log into the text console there using your regular user + password, and then startx there using: startx This will give you just an xterm, now move the mouse over the terminal so you can type in it and type: openbox& Leave the xterm running, and use your desktop as usual, if the mouse stops working, go back to the xterm and do: openbox --replace In there, now your other apps should stay open and the questions I've for you are: 1) Do your other apps stay open, or do you get thrown back into the text console 2) If you get thrown back into the text console are there any message there ? 3) If you get thrown back into the text console, please copy /var/log/Xorg.1.log to your home dir, and attach it here 4) If you do *not* get thrown back into the text console, does the openbox --replace fix your mouse issue ? Thanks & Regards, Hans
Thanks for taking the time to help me work this out, Hans. As bugs go, this bug is irritating but I can work around it. I'm very grateful that you're taking the time to try and resolve this. I reproduced the original bug easily. As soon as I launched openbox (by typing openbox&, not openbox --replace) from xterm, the symptoms disappeared. How could I bypass the greeter entirely and start only xterm when my system reaches run level 5 (or whatever systemd calls it now)? Would that be a useful experiment?
systemctl set-default multi-user.target seems to leave me at the console rather than booting to graphical.target. I managed to reproduce this once by booting to multi-user.target, startx, openbox. I had left openbox in the foreground of that xterm session so I fumbled and tried to kill it which didn't go well. When I see symptoms again I'll report back.
Answers to your questions from comment #8: 1) My apps stay open and I'm not thrown back to the text console 2) na 3) na 4) it did not fix my issue the first time, it did fix my issue the second time.
(In reply to John Schmitt from comment #11) > Answers to your questions from comment #8: > > 1) My apps stay open and I'm not thrown back to the text console > 2) na > 3) na > 4) it did not fix my issue the first time, it did fix my issue the second > time. So you had to do openbox --replace twice to get the issue fixed ? Or you reproduced the issue twice, and only the second time you reproduced the issue openbox --replace helped?
Replying to comment #12: 4) I had to do openbox --replace twice to be able to use mouse clicks. Going dark for a few days, will not be able to test for some time.
(In reply to John Schmitt from comment #13) > Replying to comment #12: > 4) I had to do openbox --replace twice to be able to use mouse clicks. Ok, that is a bit weird, but at this point in time I'm convinced that this is mostly an issue with openbix itself getting into a confused state, that also explains why clicking in apps still works, since then the clicks are not handled by openbox. Changing component to openbox.
Created attachment 866569 [details] openbox --debug --replace
I just reproduced this. Using openbox --replace would not solve my problem. I had to end my X session, go back to the text console and use startx to re-launch my session which then showed no symptoms.
(In reply to John Schmitt from comment #16) > I just reproduced this. Using openbox --replace would not solve my problem. > I had to end my X session, go back to the text console and use startx to > re-launch my session which then showed no symptoms. Hmm, next time you reproduce can you try doing the --replace twice like before ?
I'm sorry for being unclear in Comment #16. To fix my problem, I issued openbox --replace --debug >> openbox.out 2>&1 multiple times and attached the output of that as shown in comment #15.
This message is a reminder that Fedora 20 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 20. 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 '20'. 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 20 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.
Fedora 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 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.