keybase-gui silently fails (no logs either)

[idletea]

I have keybase (the service) and kbfs running - and they work just fine. keybase status gives:

Username:      oefd
Logged in:     yes

Device:
    name:      owl
    ID:        c059c9d011767c93ec2eb72a1f967b18
    status:    active

Session:
    is valid:  yes
    keys:      unlocked

Key status:
    stream:    not cached
    secret:    stored
    dev sig:   cached
    dev enc:   cached
    paper sig: not cached
    paper enc: not cached
    prompt:    show
    tsec:      not cached

KBFS:
    status:    running
    version:   3.1.2
    installed: 3.1.2
    log:       /home/terry/.cache/keybase/keybase.kbfs.log
    mount:     /home/terry/documents/kbfs

Service:
    status:    running
    version:   3.1.2
    log:       /home/terry/.cache/keybase/keybase.service.log
    eklog:     /home/terry/.cache/keybase/keybase.ek.log

Updater:
    log:       /home/terry/.cache/keybase/keybase.updater.log

Platform Information:
    OS:        linux
    OS vers:   Linux 5.0.5-arch1-1-ARCH x86_64-
    Runtime:   go1.12.1
    Arch:      amd64

Client:
    version:   3.1.2

Desktop app:
    status:    not running
    version:   
    log:       /home/terry/.cache/keybase/Keybase.app.log

Config path:   /home/terry/.config/keybase/config.json
Default user:  oefd
Other users:   
Known DeviceEKs:
    deviceEphemeralKey-oefd-1-3.ek 
LocalDbStats:
Compactions
 Level |   Tables   |    Size(MB)   |    Time(sec)  |    Read(MB)   |   Write(MB)
-------+------------+---------------+---------------+---------------+---------------
   1   |          1 |       4.25807 |       0.04446 |       4.46815 |       4.25807
-------+------------+---------------+---------------+---------------+---------------
 Total |          1 |       4.25807 |       0.04446 |       4.46815 |       4.25807

levelDbCleaner{cacheSize: 82, lastRun: 2019-04-04 11:21:23.744797326 -0400 EDT m=-3239.989130480, lastKey: [], running: false}
DbCleanerConfig{MaxSize: 2.1GB, HaltSize: 1.6GB, CleanInterval: 1h0m0s, CacheCapacity: 100000, MinCacheSize: 10000, SleepInterval: 50ms}
 
LocalChatDbStats:
Compactions
 Level |   Tables   |    Size(MB)   |    Time(sec)  |    Read(MB)   |   Write(MB)
-------+------------+---------------+---------------+---------------+---------------
   1   |          1 |       0.08804 |       0.07514 |       0.09737 |       0.08804
-------+------------+---------------+---------------+---------------+---------------
 Total |          1 |       0.08804 |       0.07514 |       0.09737 |       0.08804

levelDbCleaner{cacheSize: 18, lastRun: 2019-04-04 11:21:23.74591354 -0400 EDT m=-3239.988014219, lastKey: [], running: false}
DbCleanerConfig{MaxSize: 2.1GB, HaltSize: 1.6GB, CleanInterval: 1h0m0s, CacheCapacity: 100000, MinCacheSize: 10000, SleepInterval: 50ms}
 
CacheDirSizeInfo:
/home/terry/.cache/keybase: 1.2MB, (0 files)

command-line client:
    keybase status [cid: 7, pid: 2391, version: 3.1.2]

KBFS:
    /usr/bin/kbfsfuse -debug -log-to-file [cid: 1, pid: 1842, version: 3.1.2]
    Notification subscriptions: Session, Favorites, Paperkeys, Keyfamily, Service, Kbfsrequest, Reachability, Team, Chatkbfsedits

which all looks fine to me, but the problem starts when I want to get the GUI going. keybase-gui will run and give a 0 exit code, but the status is unchanged:

Desktop app:
    status:    not running
    version:   
    log:       /home/terry/.cache/keybase/Keybase.app.log

and the log file Keybase.app.log does not exist after running keybase-gui. (but other log files do, and they seem to contain nothing about the failure of the GUI)

I wouldn't be surprised if the key issue is that I'm trying to run this on wayland/swaywm, but even if it's some issue outside of keybase' hand that the gui can't work in that environment yet it seems like a problem in its own right that it's possible for a failure that emits no logs or error messages, and still happily lets keybase-gui exit with 0.

[heronhaye]

I assume you're using the Keybase community package. cc @eli-schwartz who maintains it (Keybase maintains keybase-bin from the AUR).

@oefd, could you try keybase ctl init && keybase-gui?

[eli-schwartz]

$ cat /usr/bin/keybase-gui
#!/bin/sh

systemctl --user import-environment KEYBASE_AUTOSTART
systemctl start --user keybase.gui.service

This is the shim script I install to emulate the run_keybase script, as the community package does not, for example, provide the suid redirector.

I can start up the GUI using this systemd startup process and find newly appended log data from today in /home/eschwartz/.cache/keybase/Keybase.app.log

[eli-schwartz]

Note that in respect to the default working of run_keybase, it runs as a systemd service and expects DISPLAY to be set. So using the keybase.io distributed bin packages would have the same expectations.

On Arch Linux, this is usually accomplished by executing /etc/X11/xinit/xinitrc.d/50-systemd-user.sh as part of xorg initialization, if you're using wayland then you should be performing a similar setup. I don't use wayland and am unsure whether there is any default integration similar to xorg's ~/.xinitrc (or if wayland uses DISPLAY, I seem to see mention of WAYLAND_DISPLAY instead?).

[heronhaye]

fwiw @eli-schwartz, we've gotten a few bug reports from Arch users who don't have DISPLAY set, but I didn't find out if they were using xorg or wayland. Maybe it would make sense to do import DISPLAY or run keybase ctl init in the script too? (Not that I know that this would solve oefd's problem though)

[eli-schwartz]

That sounds like it would make sense. According to the help text for this command, it "Among other things, sets up a environment file", but the --dry-run output seems to indicate this is the only thing it does. Is there something I'm missing?

This new logic refactored out of run_keybase does seem pretty clean and targeted, so if it just sets up keybase's private env file it's definitely something I should add.

[eli-schwartz]

Does electron actually work on Wayland, or does it need XWayland?

[idletea]

@eli-schwartz Thanks for the help, the problem was indeed not source the xinit script. I didn't realize it'd be a problem because something with sway/xwayland was setting DISPLAY during startup which I could see in my own shells, but I guess that doesn't propagate through dbus which seems to be what the xinit script does.

I'll call this solved, and see if I can't put a little snippet about this in the Arch wiki to mention this.

@heronhaye keybase ctl init does indeed solve the issue, but whether it's something keybase should consider it something it should be responsible for is debateable. Things like making sure your session is properly set up and sources whatever inits it should is something most well featured and stable environments will do, including Gnome3 on wayland.

For what it's worth: if keybase-gui had failed on a message about being unable to start due to having no DISPLAY I would probably have managed to figure this independently. (And I'll add this issue to the Arch wiki to help clarify it for anybody else with the same problem)

[eli-schwartz]

Maybe the error message was in journalctl --user -u keybase.gui.service.

[heronhaye]

@oefd glad it's solved.

@eli-schwartz
Not right now, but it might do more in the future (only done if absolutely necessary, there are no plans on adding new things there unless it really can't be resolved in the service daemon itself).

Actually, and I wasn't able to do this in the official package because Debian's systemd is ancient, you could package a systemd environment generator (https://www.freedesktop.org/software/systemd/man/systemd.environment-generator.html) that mirrors the variables forwarded by keybase ctl init. That would probably be the cleanest solution but it's a bit more work for you. To ensure the generator and the go command are kept in sync, I can add a environment generator file to the client repo but not actually use it anywhere in the official package, but you can install it in the Arch package script. What do you think?

[eli-schwartz]

@heronhaye I think the keybase-specific environment file is fine.

More generally, @oefd I think I can solve the missing error message by using systemctl --user start --wait keybase.gui.service, the --wait flag means that keybase-gui would stay in the foreground until the service itself stops, then return 0 or 1 depending on how the service exited. Would probably make more sense when running via the command line.

[eli-schwartz]

I'm currently uploading a new keybase package for release 3.2.1 which contains both changes that were discussed.