Description of problem: From time to time the system stops accepting keyboard input though the mouse still works. This happens frequently enough to be a real annoyance. It almost always happens when I'm using an SSH console session to write programs with a text-based editor (microEmacs 4.00) on another (Fedora 16-based) computer on my LAN. This usually seems to happen when I'm entering text into the remote editor and a notification, saying that the local machine's copy of Evolution has received mail, is displayed. However, I've also seen it happen when I was running a copy of Office Libre Calc remotely. This had been launched from an SSH session, so a remote console window was open behind Calc's window. I think the XFCE notifications daemon is involved because I never saw this problem before I installed F17 with XFCE on the local machine, a Lenovo R61i (1.6 GHz coreDuo, 3GB RAM). The machine also has Gnome 2 installed, because the installer silently installed it, and KDE (not normally used). Both F17 and F16 systems are fully updated as of Friday, 19th October 2012. The keyboard usually becomes active again after logging out and in again: fortunately I can log out with the mouse, though of course I can't close text-based applications cleanly on either the local or the remote system. About every 4 or 5 ocurrences logout/login doesn't clear thee problem and a full reboot of the local system is needed. The remote system has never needed a reboot after this has happened. Version-Release number of selected component (if applicable): Current versions of all Fedora 16 and 17 components as at 19/10/12 How reproducible: Happens regularly, i.e. at least once every day I spend coding, but I don't know how to cause it deliberately. Steps to Reproduce: 1. Open a remote SSH session with Evolution running on the local machine. 2. Start an editor or Office Libre application from the remote command line and use it intensively through the keyboard. 3. If you are actively typing when Evolution puts up a 'New mail' notification the keyboard will lock up. Actual results: The keyboard locks up and nothing (local or remote) responds to any keypresses. The mouse still works and can control both local and remote applications. Expected results: The local and remote systems should continue to respond to the keyboard regardless of and notifications that the local system may display. Additional info: Nothing more I can think of.
Thanks for submitting this bug report. I have never seen this problem or heard of it before. (In reply to comment #0) > It almost always happens when I'm using an SSH console session to write > programs with a text-based editor (microEmacs 4.00) on another (Fedora > 16-based) computer on my LAN. Does it only happen when you use this particular program or is a remote shell enough? > This usually seems to happen when I'm entering > text into the remote editor and a notification, saying that the local > machine's copy of Evolution has received mail, is displayed. However, I've > also seen it happen when I was running a copy of Office Libre Calc remotely. > This had been launched from an SSH session, so a remote console window was > open behind Calc's window. And how was xfce4-notifyd involved in the second case? > I think the XFCE notifications daemon is involved because I never saw this > problem before I installed F17 with XFCE on the local machine, [...] Please install GNOME's notification-deamon and uninstall xfce4-notifyd. Does the problem still occur after a logging into Xfce again? > Version-Release number of selected component (if applicable): > Current versions of all Fedora 16 and 17 components as at 19/10/12 Please run 'rpm -q xfce4-notifyd xfce4-settings xfconf Terminal' to find out the versions. "Current versions" wont work if we look at this bug in half a year. ;) > Steps to Reproduce: > 1. Open a remote SSH session with Evolution running on the local machine. > 2. Start an editor or Office Libre application from the remote command line > and use it intensively through the keyboard. > 3. If you are actively typing when Evolution puts up a 'New mail' > notification > the keyboard will lock up. Can you reliably trigger the problem if you display a notification through notify-send?
> Does it only happen when you use this particular program or is a remote > shell enough? > I don't think I've seen it when working locally: at least I can't recall an occurrence, but it did take quite a while to work out the circumstances that cause it. If I'm concentrating on a console window at bottom left its quite likely I won't notice a pale pop-up at top right. >And how was xfce4-notifyd involved in the second case? > Same situation (SSH session, same remote user, in the same directory) except that instead of using a remote text editor I was running oocalc. I have X11 forwarding turned on as part of my standard ssh configuration. The only thing I have running locally that regularly generates notifications is Evolution. > Please install GNOME's notification-deamon and uninstall xfce4-notifyd. Does > the problem still occur after a logging into Xfce again? > Since G2 is installed, I assume that its notification daemon is installed. How can I cause XFCE to use it? I'd prefer not to use G2 even for this test because I dislike it very strongly, especially its habit of defaulting app windows to load at top left of screen and then expanding the top left hot spot so it invades the left end of the application's menu bar. Bleeeaaah. > Please run 'rpm -q xfce4-notifyd xfce4-settings xfconf Terminal' to find out > the versions. "Current versions" wont work if we look at this bug in half a > year. ;) > xfce4-notifyd-0.2.2-6.fc17.i686 xfce4-settings-4.8.3-4.fc17.i686 xfconf-4.8.1-2.fc17.i686 Terminal-0.4.8-2.fc17.i686 > Can you reliably trigger the problem if you display a notification through > notify-send? > No. I tried using: sleep 4; notify-send --app-name="MyApp" --expire-time=5000 "Test notification" which gives me time to be typing before the notification appears. I have not been able to reproduce the problem this way. I would like to point out that this pop-up is smaller, uses different colours and is considerably less ornate that the one that Evolution 3.4.4 displays. The same applies to the notification generated by XFCE's Notification control applet. Is this significant? Is there any workround? ======================= If I could turn notifications off I would, since they are more annoyance than help, but the XFCE Notication control applet doesn't allow that and there is nothing in Evolutions preferences either. Is there any other way to get rid them?
(In reply to comment #2) > I don't think I've seen it when working locally: at least I can't recall an > occurrence, but it did take quite a while to work out the circumstances that > cause it. If I'm concentrating on a console window at bottom left its quite > likely I won't notice a pale pop-up at top right. My question was not about locally vs. remote abut about microEmacs. Does ot only happen with that particular or is working in a remote shell enough? > Since G2 is installed, I assume that its notification daemon is installed. > How can I cause XFCE to use it? Uninstall xfce4-notifd. It's a bug in dbus-activation that if two programs provide the same service (in this case org.freedesktop.Notifications), it will use the one that was installed later. This means you can switch by reinstalling a package. > I would like to point out that this pop-up is smaller, uses different > colours and is considerably less ornate that the one that Evolution 3.4.4 > displays. The same applies to the notification generated by XFCE's > Notification control applet. Is this significant? So when you configure xfce4-notifd and have it display a preview, this is differnt from what evolution displays? Both should use the same notification daemon and thus things should look the same. Of course one can add an icon or a button here or there, but the general look and feel should be the same. > If I could turn notifications off I would, since they are more annoyance > than help, but the XFCE Notication control applet doesn't allow that and > there is nothing in Evolutions preferences either. > > Is there any other way to get rid them? What happens if you edit /usr/share/dbus-1/services/org.xfce.Notifications.service and change the line that reads Exec=/usr/lib64/xfce4/notifyd/xfce4-notifyd to something like Exec=/bin/true Do you still get notifications from evolution and do you still hit this bug?
Re your question about Microemacs. No, it isn't the only app that can cause this problem. I've also seen it when using the XFCE calculator, gcalctool 6.4.2.1, in a local session. Microemacs is a text-mode programmers editor, written in C and using termcap for its screen management. I've ported it to and used it on NCR and DEC unices (X86 and Alpha respectively) as well as Microware OS-9/68000, MS-DOS, Fedora and, most recently, ARM-Debian on a RaspberryPi. Porting means customising by selecting features in one header file and compiling it. Evolution using a different notification panel was a misstatement. Ignore it. I tried changing the line in /usr/share/dbus-1/services/org.xfce.Notifications.service to Exec=/bin/true The notifications stopped appearing but the keyboard lockouts still happened and Evolution became very slow in a sporadic fashion. Very slow means 20+ seconds to open a message that is already in the inbox. Does it expect an ack from the notification daemon after a notification has been displayed? I've also noticed a way of causing the lockout: holding the Ctrl key down for several seconds does it. This is a habit I have sometimes when thinking as I type. I didn't think Ctrl was a repeating key bit, if it is, could this be causing a buffer overflow? I haven't tried switching to the Gnome notification daemon because replacing the daemon with /bin/true didn't have any effect on the keyboard lockouts: if you still want that tried please say so.
I've had this same problem with Fedora 17 and now Fedora 18. I decided to monitor /var/log/Xorg.?.log, and I noticed that when the keyboard lock up happened, I got the following entry in the log: [ 13892.512] (II) XKB SlowKeys are now enabled. Hold shift to disable. [ 13892.512] (II) XKB SlowKeys are now enabled. Hold shift to disable. Holding down the (right) shift key for several seconds then produced the following entry: [ 13974.360] (II) XKB SlowKeys are disabled. [ 13974.360] (II) XKB SlowKeys are disabled. and the keyboard started working again! I now have a work-around, but it would be much better if this never happened in the first place.
(In reply to comment #4) > I haven't tried switching to the Gnome notification daemon because replacing > the daemon with /bin/true didn't have any effect on the keyboard lockouts: > if you still want that tried please say so. Yes, please do. Please install GNOME's notification daemon and edit the dbus service file to execute /usr/libexec/notification-daemon. (In reply to comment #5) > I've had this same problem with Fedora 17 and now Fedora 18. I doubt this is related, you are not mentioning that any notifications were involved. > I decided to > monitor /var/log/Xorg.?.log, and I noticed that when the keyboard lock up > happened, I got the following entry in the log: > > [ 13892.512] (II) XKB SlowKeys are now enabled. Hold shift to disable. > [ 13892.512] (II) XKB SlowKeys are now enabled. Hold shift to disable. Slow keys are an accessibility feature that can be enabled in xfce4-accessibility-settings or via pressing shift for several seconds. So I guess your problem is unrelated to this bug report, but nevertheless I'd like to ask Martin if he sees the same in his Xorg logs. I cannot reproduce any of the problems the two of you described.
So does one of you have any clue that this really related to xfce4-notifyd? AFAICS only slow keys got enabled, that's all.
(In reply to comment #7) > So does one of you have any clue that this really related to xfce4-notifyd? > AFAICS only slow keys got enabled, that's all. My problem was just "slow keys", and not related to xfce4-notifyd.
This 'slow keys' thing looks like what I've been seeing: I grepped /var/log/Xorg.* and found two examples of "XKB SlowKeys are now enabled. Hold shift to disable." As I hadn't been looking at the top right screen corner (and had been concentrating on that I was doing) when the keyboard locked, I'd seen a notification appear but had not looked at it quickly enough to read it. Just now I tried holding SHIFT down and sure enough, got a 'Slow Keys enabled' notification. Doing it a second time got a 'Slow keys disabled' notification. and the Xorg logs now contain four more "XKB Slowkeys" messages (two for enabling it followed by to for disabling it. I've just looked at the XFCE4 'Accessibility control panel and saw, to my surprise, that the 'Use Slow Keys' box is unchecked. This is a surprise because: (a) I expected it to be checked. (b) When the panel is displayed the check box content does not show whether 'Slow Keys' is enabled or disabled. This looks like a bug to me. For starters, surely the checkbox should show whether 'Slow Keys' is enabled or not. In addition, I think that a second check box is needed to enable or disable this special meaning of a long shift press.
This message is a reminder that Fedora 17 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 17. 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 WONTFIX if it remains open with a Fedora 'version' of '17'. 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 prior to Fedora 17's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 17 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 to Fedora 17's end of life. 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 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 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. Thank you for reporting this bug and we are sorry it could not be fixed.