keys.db not found when starting lcd

[faboweb]

Steps to Reproduce

electron  spawning /Users/fabo/Development/voyager/builds/Gaia/darwin_amd64/gaiacli with args ""rest-server" "--insecure" "--laddr" "tcp://localhost:9070" "--home" "/Users/fabo/.cosmos-voyager-dev/test-chain-utesL3/lcd" "--node" "http://localhost:26657" "--chain-id" "test-chain-utesL3" "--trust-node" true"

electron  gaiacli exited with code 0

electron  gaiacli: panic: stat /Users/fabo/.cosmos-voyager-dev/test-chain-utesL3/lcd/keys/keys.db: no such file or directory

          goroutine 1 [running]:
          github.com/cosmos/cosmos-sdk/client/lcd.createHandler(0xc000161a40

electron  gaiacli: , 0x5)
                /go/src/github.com/cosmos/cosmos-sdk/client/lcd/root.go:139 +0x61c
          github.com/cosmos/cosmos-sdk/client/lcd.ServeCommand.func1(0xc000b51b00, 0xc000b2e840, 0x1, 0xb, 0x0, 0x0)
                /go/src/github.com/cosmos/cosmos-sdk/client/lcd/root.go:49 +0x8d
          github.com/cosmos/cosmos-sdk/vendor/github.com/spf13/cobra.(*Command).execute(0xc000b51b00, 0xc000b2e790, 0xb, 0xb, 0xc000b51b00, 0xc000b2e790)
                /go/src/github.com/cosmos/cosmos-sdk/vendor/github.com/spf13/cobra/command.go:698 +0x47a
          github.com/cosmos/cosmos-sdk/vendor/github.com/spf13/cobra.(*Command).ExecuteC(0x261a840, 0x6, 0xc000b66320, 0x0)
                /go/src/github.com/cosmos/cosmos-sdk/vendor/github.com/spf13/cobra/command.go:783 +0x2dc
          github.com/cosmos/cosmos-sdk/vendor/github.com/spf13/cobra.(*Command).Execute(0x261a840, 0x1a6680a, 0x6)
                /go/src/github.com/cosmos/cosmos-sdk/vendor/github.com/spf13/cobra/command.go:736 +0x2b
          github.com/cosmos/cosmos-sdk/vendor/github.com/tendermint/tendermint/libs/cli.Executor.Execute(0x261a840, 0x1e22640, 0x0, 0xc0000c34e0)
                /go/src/github.com/cosmos/cosmos-sdk/vendor/github.com/tendermint/tendermint/libs/cli/setup.go:89 +0x4e
          main.main()
                /go/src/github.com/cosmos/cosmos-sdk/cmd/gaia/cmd/gaiacli/main.go:140 +0xca9

ref: #2656

---

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate contributors tagged
• Contributor assigned/self-assigned

[jackzampolin]

@faboweb Can you include exact steps to reproduce using only CLI commands?

[faboweb]

Here are the commands leading up to the error:
gaiad init --home /Users/fabo/.gaiad-testnet --name local -o --overwrite-key
gaiacli rest-server --insecure --laddr tcp://localhost:9070 --home /Users/fabo/.cosmos-voyager-dev/test-chain-e1lAKm/lcd --node http://localhost:26657 --chain-id test-chain-e1lAKm --trust-node

[jackzampolin]

When I run this, gaiad init creates the ~/.gaiad-testnet and ~/.gaiacli folders. The --home option in the second command points to a folder that isn't created. Switching the second command to --home $HOME/.gaiacli makes this error go away. Is this issue about the panic (which we should fix), or is there some behavior in the CLI that changed?

[faboweb]

But I need the gaiacli folder to be defined manually. Is that not possible anymore?

[alexanderbez]

Should be able to? Is there a db actually there?

[jackzampolin]

Looks like you also need to set the --client-home when you run gaiad init

[faboweb]

I think before the keys db was just created automatically. Now I need to run gaiad init --client-home ... which is possible but tedious. It requires an LCD application to also include the gaiad binary and to create a temporary gaiad config folder it doesn't need.

[alexanderbez]

@faboweb Im a bit confused by the problem/scenario that is causing trouble here. Do you mind summarizing please?

[faboweb]

With the latest SDK it is not possible anymore to just start the LCD with gaiacli rest-server.... This would result in no keys db being found. One has to initialize the client-home directory manually using the gaiad binary.

Why was this changed?
Can we make the gaiacli binary self sustained again?

[jackzampolin]

@faboweb Agree that we should make the gaiacli binary a standalone, but above you show running gaiad init right before trying to run the gaiacli rest-server command. Just adding the --client-home should fix this issue in the short term correct?

We should separate these concerns so we aren't running into this type of confusion.

[faboweb]

gaiad init --home /Users/fabo/.gaiad-testnet --name local -o --overwrite-key is just setting up a testnet node in development and not for production.

In addition one needs to init the keys.db and then delete the default account used to create it. Which feels excessive.

[alexanderbez]

Ahhh I see. Yes I am able to reproduce this and this should be fixed. I don' think we should have to force usage of --client-home @jackzampolin imho.

I think this was a side effect of the KeyBase R/W permissions update. I'll see if I can fix this quickly.

[alexanderbez]

Mhmm, actually nvm. Not sure what is going on at first glance.

Update: So this IS due to the new KeyBase opening with R/W options.

See the goleveldb function:

// OpenFile returns a new filesystem-backed storage implementation with the given
// path. This also acquire a file lock, so any subsequent attempt to open the
// same path will fail.
//
// The storage must be closed after use, by calling Close method.
func OpenFile(path string, readOnly bool) (Storage, error) {
	if fi, err := os.Stat(path); err == nil {
		if !fi.IsDir() {
			return nil, fmt.Errorf("leveldb/storage: open %s: not a directory", path)
		}
	} else if os.IsNotExist(err) && !readOnly {
		if err := os.MkdirAll(path, 0755); err != nil {
			return nil, err
		}
	} else {
		return nil, err
	}

    // ...
}

We pass ReadOnly: true when we open the KeyBase via GetKeyBase. Before (e.g. 0.24) we didn't set options, so ReadOnly: false. If we look at the method, we notice it ONLY creates a new directory if it doesn't exist AND ReadOnly is false.

An easy fix is to simply create it on our side if it doesn't exist. I'll do this.

/cc @alessio

[alexanderbez]

Soooo looks like @alessio already opened an issue for this haha: #2656

I still don't think we need to wait for that upstream fix.