Option to exit with error if keyring cannot be unlocked

[peterhoeg]

The problem

Sometimes maestral starts up faster than the keyring (kwallet my case) thus causing maestral to run but not actually work:

systemd[1143]: Starting Maestral - OpenSource Dropbox client...
systemd[1143]: Started Maestral - OpenSource Dropbox client.
maestral[1697]: ! Could not load auth token. kwallet DBusKeyring is locked. Please unlock the keyring and try again.

So now it looks like everything is OK but nothing is obviously being synced.

The solutions There are a few ways we could handle this:

1. the quick way is to add a --exit-unless-unlocked or similar flag that would make the main process exit if it couldn't read the token. This way systemd will then restart the process and presumably the keyring would then be available.

2. alternatively just keep retrying every X seconds. If combined with the flag above, exit after Y failures.

[samschott]

Oh, I can see indeed how this is annoying.

If you manually pause and resume syncing, it should retry accessing the keyring and will start syncing if successful. However, "fatal" error messages are currently not cleared if we recover from them, it will therefore still show up as a red error message in the CLI.

But this doesn't really help you because it still requires manual intervention. A flag to exit on all fatal errors (keychain locked, database integrity error, revoked token, etc...) or on specific fatal errors could be useful here. For example --exit-on-error KEYRING_LOCKED.

Alternatively, how about starting the maestral service only after the keyring has been started and unlocked? Start-on-login of the daemon is supported only through systemd anyways require the keyring service to be up and running. This only becomes problematic when user has manually specified a different keyring backend in the config file, for instance forcing the use of a plain-text backend and keeping the system keyring locked.

[peterhoeg]

Alternatively, how about starting the maestral service only after the keyring has been started and unlocked?

The problem with that is that we only have a sync point for when the backend is running (in my case that systemd reports kwalletd is running) but it doesn't mean that the keyring is unlocked if the keyring password is different from the login password or it simply is in a different keyring.

The most elegant solution would be to have certain errors be "automatically retryable". That would make it work whenever the keyring is accessible and should logically also clear the error state.

But the exit on error would totally do it too.

Thanks again for maestral!

[peterhoeg]

This just hit me again. I'm not sure how long maestral hasn't been syncing. If the daemon had failed, at least I would have known much earlier.

--exit-on-error KEYRING_LOCKED would be great to have!

[peterhoeg]

So this is what happened: https://github.com/samschott/maestral/issues/734

[KuleRucket]

My kwallet is locked with a password. If I have maestral auto starting, then it will already fail before I enter the password, meaning that every time I log in I have to manually fix maestral. This is terrible behaviour for something that is supposed to silently backup my stuff in the background.

EDIT: The only workaround I found was to have a KDE wallet with no password.