Linux Keybase hangs when it can't sent notifications (was "steal focus")

[jbash]

I'm running the Linux Keybase GUI under FVWM and the XFCE panel on Fedora 29.

Any time there's an incoming chat message and I don't have the cursor over the Keybase window, the program hangs completely for probably a minute or two. It ignores all user events and won't repaint its window. Eventually it recovers completely... until the next message comes in. This happens regardless of whether theKeybase window is in front, obscured, or not open at all.

I suspect that the real triggering condition is not "mouse is not over the window", but "window does not have the keyboard focus and the program can't grab it". I have FVWM configured for focus-follows-mouse, because click-to-focus is morally wrong. Therefore Keybase usually won't have the focus if the mouse isn't over the window. Even more unusually, I've tried to configure FVWM to prevent all programs from stealing focus. Assuming that's working right, which I haven't really tested, Keybase will not get the keyboard if it tries to take it.

I get the feeling that it's trying, and reacting poorly to failure.

I'd like to convince you that chat apps shouldn't try to grab the keyboard in the first place. It amounts to a "randomly send a password to a friend every once in a while" feature. However, since every chat app seems to do it, I'm afraid I'll fail to convince you.

... but I'd at least like it if the program didn't actually hang if it can't steal the focus. And maybe you could at least have the option of not trying?

My FVWM config file is attached: config.txt

[heronhaye]

That's definitely odd behavior. What is your keybase version? Could you trigger this behavior and then keybase log send?

(By the way, that file shows up as empty for me)

[jbash]

What is your keybase version?

Client: 4.1.0-20190612201656+952fee6c59 Service: 4.1.0-20190612201656+952fee6c59

Could you trigger this behavior and then keybase log send?

I would prefer to see what it's going to send before I send anybody any debug logs. The help doesn't say how I can do that (or even that I can do it...).

(By the way, that file shows up as empty for me)

That's odd, because I just downloaded it back from GitHub and it looks fine to me.

[heronhaye]

@jbash sure, it will send the contents of keybase status and the contents of each of the log files listed there (e.g., keybase.service.log). On systems with systemd, it will also send a tail of the systemd user units for {keybase,kbfs,keybase.gui,keybase-redirector}.service, and the list of processes running whose name matches keybase|kbfs. If you prefer, you can send redacted versions directly to me over KBFS or email.

That's odd, because I just downloaded it back from GitHub and it looks fine to me.

Works for me now.

(fwiw: I've never used FVWM but I use i3wm with focus follows mouse and have never experienced the behavior you describe. It is definitely a bug, not intended).

[jbash]

I went and found what appear to be the logs and made some extracts. There was a hang on an incoming message that the UI logged at 15:42, and a couple of other things around there. I've included eveything from 15:40 to 15:46.

There was nothing at the relevant times in the "ek" or "kbfs" logs, even after compensating for time zones.

Keybase.app.txt keybase.service.txt

... and on edit I see that you gave me detailed instructions. I'll try to get the systemd stuff for you.

[heronhaye]

@jbash, I don't believe Fedora uses the systemd units actually. You can check with systemctl --user is-active keybase. (My understanding is that systemd user manager isn't supported yet, but could be wrong)

[heronhaye]

One more question: is this new behavior with this release or have you always had this even in older versions of Keybase?

Also, do you have any other window managers or are you able to test FVWM with a blank config? Keybase shouldn't try to steal your focus any time, it doesn't in i3.

[jbash]

The only unit that has any systemd journal entries other than starts, stops, and reboots is the keybase.gui one. The journal is attached.

The "failed to connect to proxy" messages might correspond to the hangs, but I'm not sure. I don't remember configuring any proxies and don't see anything in the GUI that would let me configure them.

I think the texture messages are associated with a different bug where stuff in the UI turns black and I have to restart the program.

systemd-keybase.gui.txt

[jbash]

I started trying to use the Linux Keybase GUI probably a month or two ago, and it's always done this.

I can try for a different WM or a blank FVWM config, but I'm not confident that either will give meaningful results. A blank FVWM config may not even work. I can also try to avoid loading the XFCE panel, which probably launches a bunch of "desktop components".

Speaking of avoiding, My other weirdness is that I usually try not to load any "desktop components" that I can avoid, and may be leaving out something that Keybase expects. I've been avoiding that stuff since Gnome and KDE showed up, and I've to be dragged kicking and screaming into each new abomination since about 1989. I mean, dbus is running, but that doesn't mean I approve of dbus.

It may take me some time to get closer to vanilla, and even longer to figure out exactly what non-vanilla part triggers this.

[jbash]

Oh, and Fedora does use per-user systemd. I think it has for quite a while. In fact you just made me discover a bunch of new user units to try to turn off. :-)

[heronhaye]

Hmm, I wonder if it's a problem with notifications. Does notify-send test work?

Does the GUI also freeze if you do something like ls "$(keybase config get -b mountdir)/private/notme" (which should show a notification for "Permission denied").

[jbash]

Hmm. I'm sorry; it looks like I may have been misled and misled you.

It looks like it's not that it hangs when it doesn't have focus at all. It's that it hangs when it receives a message from a user other than me (which of course usually happens when it doesn't have focus). If I send the message, even from another device, nothing hangs, regardless of the focus. Should I change the headline?

During each hang, there are about three of the "Failed to connect to proxy" messages in the systemd journal. Each of those messages is associated with an strace log entry like this:

16047 18:00:56.617442 openat(AT_FDCWD, "/home/jbash/.local/share/keybase/fileoutbox/a-bunch-of-hex", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)

It looks like it polls for that file several times at five second intervals, then gives up and issues the "Failed to connect" message, then tries several more series of polls. There are a lot of PIDs involved and I'm not sure which threads belong to which processes.

During all of this, it looks like the "gpu-process" is mostly issuing recvmsg calls on a UNIX socket that's connected to I know not what, and failing with EAGAIN.

[jbash]

"notify-send test" does nothing for about 30 seconds, produces no output, and exits with status 0.

The GUI does freeze on the "ls" command. The "ls" command itself comes back fairly quickly with permission denied.

[heronhaye]

Ok, that sounds like an issue with notifications then. Do you have libnotify and a notification server like dunst?

[jbash]

I do have libnotify. I did not personally install it, nor did I know that it existed. Yeat another "desktop component". As far as I know I don't have a notification server running. I probably don't want one, but I'll try installing one and let you know the result.

[jbash]

With dunst installed and running, notify-send test comes back immediately, and neither ls "$(keybase config get -b mountdir)/private/notme" nor an actual incoming message hangs the Keybase GUI. None of the above creates a notification (the chat window was already on the screen when the incoming message arrived).

I updated the headline; I assume that's what you guys would want.

This ceases to be urgent for me since I have a workaround. I won't close it because I assume you don't want to actually hang like that no matter what.

[jbash]

Oh, and thank you for being so responsive and putting up with my bad guesses.

[tsloughter]

I have this same issue and thought turning off notifications would fix it (I've had this same issue with other chat apps (like Signal) that use notifications that are fixed by turning them off).

And installing dunst did not stop the hanging... I already have a notification client called mako installed but I tried installing dunst as well and the same freezing happens.

Maybe it is related to being in the systray? I don't see an option to disable that, is there one?

[tsloughter]

Ok, I mostly figured it out this time.

Turned out mako was installed but not running. And with it running I'm getting notifications when there are new messages. I thought I'd turned those off. I had unchecked display desktop plaintext notifications but I guess that isn't the config for getting notifications about new messages.

Is there a way to disable notifications? Right now I can at least keep it from freezing but I'd rather not see any notifications.

[heronhaye]

Right now the only way is to go the info pane for every chat and disable desktop notifications there. You might also be able to configure mako to ignore notifications from Keybase.

[tsloughter]

Ah, thanks! I was looking for a global option, didn't think to check in the individual chat's options.