I reinstalled Arch Linux on my laptop and reinstalled keybase from the aur. However the app will not launch. I have verified that laptop is trust on the website. There anything else I am missing?
my log id: 2e5ce8a7269b742d288c631c
JR1994
All 26 comments
According to your logs, you already have a veresion of the keybase app running. Kill the existing app and try again.
maxtaco
on 24 Jun 2017
killed the running app and it still did not launch.
JR1994
on 24 Jun 2017
cc: @oconnor663 for arch support
maxtaco
on 26 Jun 2017
@JR1994 could you tell us more about what you're trying? If you run ps aux | grep -i keybase, what do you see? If you restart your machine, does it fix the problem?
The GUI app uses Electron's makeSingleInstance function to limit the number of instances running. You can see the error yourself if you run /opt/keybase/Keybase:
Only one instance of keybase GUI allowed, bailing!
On my machine, even if I kill -9 the running instance, a second instance is able to start after it dies. But I don't know exactly how Electron implements this.
oconnor663
on 26 Jun 2017
Ok here is what I am seeing.
- I see keybase running in the background
[rican-linux@archlinux-gazelle ~]$ ps aux |grep -i keybase
rican-l+ 4636 0.0 0.1 777376 41556 ? Sl Jun25 0:13 keybase -d --log-file=/home/rican->linux/.cache/keybase/keybase.service.log service --auto-forked
rican-l+ 4637 0.0 0.0 784028 31048 ? Sl Jun25 0:12 kbfsfuse -debug -log-to-file /keybase
rican-l+ 14608 0.0 0.0 10788 2176 pts/0 S+ 13:26 0:00 grep -i keybase
- I kill the keybase process and launch keybase app and nothing happens. I ps again and see the app running again. I kill it and try to launch from the terminal using run_keybase. I get the following
run_keybase
Unmounting /keybase...
Shutting down kbfsfuse...
Launching keybase service...
Mounting /keybase...
Launching Keybase GUI...
Success!
However the app is not launching.
JR1994
on 26 Jun 2017
@JR1994, what's the output of /opt/keybase/Keybase when you try running that directly?
oconnor663
on 26 Jun 2017
@oconnor663, this is what I get
[rican-linux@archlinux-gazelle ~]$ /opt/keybase/Keybase
Only one instance of keybase GUI allowed, bailing!
[rican-linux@archlinux-gazelle ~]$
So I went into my setting made sure keybase was not set to autostart and rebooted. I loggged back in, ran the command, and got the same output.
JR1994
on 27 Jun 2017
Very interesting. I don't really have a theory. @cjb @chrisnojima, do you guys know what could make the runSingleInstance machinery get all confused?
oconnor663
on 27 Jun 2017
Here is some more info I am running KDE when I had it working it was under
GNOME. Would that make a difference?
On Tue, Jun 27, 2017 at 12:28 PM, oconnor663 notifications@github.com
wrote:
Very interesting. I don't really have a theory. @cjb
https://github.com/cjb @chrisnojima https://github.com/chrisnojima,
do you guys know what could make the runSingleInstance machinery get all
confused?—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/keybase/client/issues/7504#issuecomment-311460259,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFHmIE4jmWRAhkqmV1ATllDZUHSEgDVaks5sIVfQgaJpZM4OEE4e
.
JR1994
on 27 Jun 2017
This is part of electron and not our code so I have no idea offhand
chrisnojima
on 27 Jun 2017
@oconnor663 It uses a lockfile in the config directory somewhere, I forget the name of it though. I'm surprised it doesn't forfeit the lockfile if flock(2) shows it's not in use by a running process..
cjb
on 27 Jun 2017
@JR1994 Try looking for a file called SingletonLock in $HOME/.cache/keybase or $HOME/.config/keybase and deleting it if you find one.
cjb
on 27 Jun 2017
I do not have that file.
[rican-linux@archlinux-gazelle ~]$ ls .cache/keybase/
Keybase.app.log keybase.kbfs.log keybase.service.log keybase.start.log session.json
[rican-linux@archlinux-gazelle ~]$ ls .config/keybase/
config.json secretkeys.ricanlinux.mpack
[rican-linux@archlinux-gazelle ~]$
@oconnor663 could you track down the path to SingletonLock on your machine?
cjb
on 27 Jun 2017
Found it!
[rican-linux@archlinux-gazelle ~]$ find ~/ -name SingletonLock -print
/home/rican-linux/.config/Keybase/SingletonLock
Will delete and test
JR1994
on 27 Jun 2017
@oconnor663 If this is it, I guess we could rm SingletonLock as an early part of run_keybase?
cjb
on 27 Jun 2017
that did it!
JR1994
on 27 Jun 2017
When I kill -9 my GUI process, I notice that the SingletonLock sticks around, but it still doesn't prevent another instance from starting and overwriting it. So it's not just the existence of the file that's the problem. It's possible deleting it would fix @JR1994's case, but still I want to understand what the heck is going on :)
oconnor663
on 27 Jun 2017
@JR1994 I don't imagine you saw what the symlink was pointing to before you deleted it? Was it something crazy like PID 1?
oconnor663
on 27 Jun 2017
No sorry
JR1994
on 27 Jun 2017
I just renamed it to SingltonLock.bak instead of deleting it
JR1994
on 27 Jun 2017
I'm curious what ls -lh SingletonLock.bak reports?
oconnor663
on 27 Jun 2017
Btw, here's a description of electron's mechanism: https://github.com/electron/electron/blob/master/chromium_src/chrome/browser/process_singleton_posix.cc#L5-L38
oconnor663
on 27 Jun 2017
Interesting..it recreated the file
[rican-linux@archlinux-gazelle ~]$ ls -lh .config/Keybase/SingletonLock*
lrwxrwxrwx 1 rican-linux rican-linux 22 Jun 27 13:40 .config/Keybase/SingletonLock -> archlinux-gazelle- 9231
-r-------- 1 rican-linux rican-linux 34 May 29 17:21 .config/Keybase/SingletonLock.bak
[rican-linux@archlinux-gazelle ~]$
I ran into this issue today. For me a service restart solved it. The gui appeared again.
systemctl --user restart keybase.gui.service
tiborsimon
on 31 May 2019
@tiborsimon my hero!
This should be in the readme or something...
y4my4my4m
on 20 Oct 2019
Related issues
iqballher
·
3Comments
Alexendoo
·
3Comments
Magi1053
·
3Comments
caronni
·
3Comments
kurianjacob
·
4Comments
Most helpful comment
I ran into this issue today. For me a service restart solved it. The gui appeared again.