kbfs is repeatedly trying to connect without success

[ghost]

When I typed cd /keybase/public/dtiersch the terminal doesn't respond anymore (entering only /keybase/public worked; ls showed only the folder dtiersch which is probably right) since keybase is trying to connect to the server in the background, which I could see in the log files:

2016-04-21T23:40:09.389503 ▶ [DEBU kbfs connection.go:243] 168 (CONN MDServerRemote 0e0b0b61) Connection: dialing transport
2016-04-21T23:40:09.711403 ▶ [DEBU kbfs connection.go:256] 169 MDServerRemote: OnConnect called with a new connection
2016-04-21T23:40:09.711457 ▶ [DEBU kbfs mdserver_remote.go:119] 16a MDServerRemote: resetAuth called
2016-04-21T23:40:09.812788 ▶ [DEBU kbfs mdserver_remote.go:119] 16b MDServerRemote: received challenge
2016-04-21T23:40:10.263532 ▶ [DEBU kbfs crypto_client.go:139] 16c Signed 445-byte message: err=Login required: KBFS Authentication
2016-04-21T23:40:10.263608 ▶ [WARN kbfs mdserver_remote.go:119] 16d MDServerRemote: error signing authentication token: Login required: KBFS Authentication
2016-04-21T23:40:10.263651 ▶ [WARN kbfs connection.go:258] 16e (CONN MDServerRemote 0e0b0b61) Connection: error calling OnConnect handler: libkb.LoginRequiredError{Context:"KBFS Authentication"}
2016-04-21T23:40:10.263695 ▶ [WARN kbfs connection.go:411] 16f MDServerRemote: connection error: "Login required: KBFS Authentication"; retrying in 1m3.563546944s

repeatedly for some minutes until I cancelled to send the logs.

Before I installed updated the client, rebooted the machine, and then ran run_keybase:

Launching keybase service...
Mounting /keybase...
Launching Keybase GUI...
Success!
                                                  ▄▄▄▄█▀
╭───────────────────────╮          ▄▄          ▄▄▄█▄▄▀
│                       │         ███▄▄▄▄▄▄▄▄▄▄███▄██
│  Encrypt everything!  │       ▄▄▄████▄▄▄███████████
│                       ├────  ▄▄▄▄▄████▄█████████████
╰───────────────────────╯      ███▄█▄█████████████████▄▄
                                ▀▄███████▄▀ ███████████▄▄
                                  ▄▄▄▄███    ███████████▄▄
                                 ▄████████   ██████████████
                                ▄███▄█████▄▄  ▀▄████████████
                               ███████▄▄██▄█▄▄ █████████████
                              ▄▄█████████████▄▄ ████████████
                           ▄██▄▄████▄▄▄█▄▄█████ ████████████
                                ███▄▄▄▄▄███████▄▄█████████▄▀
                                ▄█████▄▄█████████████▄█████
                                █▄██████████▄▄▄▄▄▄▄███████
                              ▄▄▄▄▄██▄▄█████▄████████████
                            ▀▀▀▀▀▀▀▀▄▄▄▄██▄▀ ▀▀▄▄▄▄▄▄▀▀▀
                                  ▀▀▀▀▀▀▀▀▀

which worked perfectly fine

Version Information:

Platform Information:
    OS:        linux
    Runtime:   go1.6
    Arch:      amd64

Client:
    version:   1.0.15-20160421160809+aff0140

my log id: ffe9c91154496a586756af1c

[maxtaco]

Try keybase unlock for now. This bug should be fixed in tomorrow's build

[ghost]

I tried again (with a reboot as a safety measure) but it's again trying for over 5 minutes now with the same error logs as above.

Here is exactly what I did this time:

dtiersch at lie42 in ~
$ keybase unlock
▶ INFO Forking background server with pid=2518
Please enter the Keybase passphrase for dtiersch (12+ characters):
dtiersch at lie42 in ~
$ run_keybase
Shutting down keybase service...
Launching keybase service...
Mounting /keybase...
Launching Keybase GUI...
Success!
                                                  ▄▄▄▄█▀
╭───────────────────────╮          ▄▄          ▄▄▄█▄▄▀
│                       │         ███▄▄▄▄▄▄▄▄▄▄███▄██
│  Encrypt everything!  │       ▄▄▄████▄▄▄███████████
│                       ├────  ▄▄▄▄▄████▄█████████████
╰───────────────────────╯      ███▄█▄█████████████████▄▄
                                ▀▄███████▄▀ ███████████▄▄
                                  ▄▄▄▄███    ███████████▄▄
                                 ▄████████   ██████████████
                                ▄███▄█████▄▄  ▀▄████████████
                               ███████▄▄██▄█▄▄ █████████████
                              ▄▄█████████████▄▄ ████████████
                           ▄██▄▄████▄▄▄█▄▄█████ ████████████
                                ███▄▄▄▄▄███████▄▄█████████▄▀
                                ▄█████▄▄█████████████▄█████
                                █▄██████████▄▄▄▄▄▄▄███████
                              ▄▄▄▄▄██▄▄█████▄████████████
                            ▀▀▀▀▀▀▀▀▄▄▄▄██▄▀ ▀▀▄▄▄▄▄▄▀▀▀
                                  ▀▀▀▀▀▀▀▀▀
dtiersch at lie42 in ~
$ keybase status
Username:      dtiersch
Logged in:     yes

Device:
    name:      work client
    ID:        ef714f650a4adcb67b3c75759206d818
    status:    active

Session:       no session
    is valid:  yes
    keys:      locked
    lksec:     not loaded

KBFS:
    status:    running
    version:   1.0.2-20160421160809+3b95761
    log:       /homes/dtiersch/.cache/keybase/keybase.kbfs.log

Service:
    status:    running
    version:   1.0.15-20160421160809+aff0140
    log:       /homes/dtiersch/.cache/keybase/keybase.service.log

Updater:
    log:       /homes/dtiersch/.cache/keybase/keybase.updater.log

Platform Information:
    OS:        linux
    Runtime:   go1.6
    Arch:      amd64

Client:
    version:   1.0.15-20160421160809+aff0140

Desktop app:
    status:    not running
    version:
    log:       /homes/dtiersch/.cache/keybase/Keybase.app.log

Config path:   /homes/dtiersch/.config/keybase/config.json
Default user:  dtiersch
Other users:

command-line client:
    keybase status [pid: 2606, version: 1.0.15-20160421160809+aff0140]

KBFS:
    kbfsfuse -debug -mdserver mdserver.kbfs.keybase.io:443 -bserver bserver.kbfs.keybase.io:443 -log-to-file /keybase [pid: 2562, version: 1.0.2-20160421160809+3b95761]
dtiersch at lie42 in ~
$ cd /keybase/public/dtiersch

[maxtaco]

The problem is that your private keys are locked. So keybase unlock doesn't help? There's a bug in our pinentry program and it will be fixed in the new build...

[ghost]

are the device NaCl-keys used here or is GnuPG required?

[maxtaco]

device NaCl

Cc: @patrickxb who is working on this bug

[ghost]

I did some random encrypt stuff so that I had to enter my password again, which this time unlocked my keys, and I could change into my public folder successfully and deposit a file there.

So that is at least a workaround

[cjb]

It looks like you ran keybase unlock but then run_keybase, which undid the unlock.

[ghost]

Ok, I was unaware that run_keybase did that. Good that I posted the complete terminal output then