Skip to content

Reduce repeated logins to Mergin Maps server - #190

Open
varmar05 wants to merge 4 commits into
masterfrom
fix_too_many_logins
Open

varmar05 wants to merge 4 commits into
masterfrom
fix_too_many_logins

Conversation

@varmar05

@varmar05 varmar05 commented Oct 6, 2026

Copy link
Copy Markdown
Contributor

Issue

Sometimes there are db-syncs logging in very frequently (e.g. every ~2 s). By design, db-sync logs in once per process, so the cause is processes being started over and over: a failing daemon restarted by Docker or another service manager, or --single-run called frequently from cron. Each new process logged in again.

Fixes

1. Retry failed start in-process instead of exiting

  • Login, --force-init cleaning and init failures are retried inside the daemon, with exponential backoff from sleep_time up to 10 min. An existing client is reused, so a failed init doesn't log in again.
  • Unexpected exceptions are caught too, not only DbSyncError.
  • New daemon.max_retries option (default 10, 0 = never exit). The daemon exits after this many consecutive failed retries of the start or of unexpected errors, and always sends a notification email when it gives up. Sync errors after a successful start are still retried indefinitely.

2. Reuse auth token across restarts

  • The token is stored in <working_dir>/.mergin_auth.json.
  • On start it's reused if it was issued for the configured server and user, has more than 1 h of validity left and the server still accepts it. Otherwise db-sync logs in normally.
  • The token survives --force-init cleaning.

3. Handle tokens rejected by the server

  • If the server rejects the token of a running daemon (401), the stored token is dropped and db-sync logs in on the next retry. Previously sync failed until the token was close to expiring.
  • Failed logins back off up to 1 h instead of 10 min, because rejected credentials can't be fixed by retrying and repeated failures may lock the account.

…of exiting

When login or init failed, the daemon exited and container / service restart
policies started it again, logging in to the server on every restart. Frequently
failing deployments potentially generated thousands of such logins.

The daemon now retries login and init within the same process,
reusing the existing Mergin client. Consecutive failures back off
exponentially; a successful sync resets the wait to sleep_time.

New daemon option 'max_retries' limits consecutive failed retries of the start
or of unexpected errors, after which the daemon exits as before and always
sends a notification email.

Sync errors after a successful start are still retried indefinitely.
This mitigates the very frequent unnecessary logins to server.

After login, the auth token is stored in <working_dir>/.mergin_auth.json.
Rejected tokens (401) are removed and a new login is done.
Stored token is kept even when the working directory is removed by --force-init cleaning.
The server may reject a token before it expires. Failed logins are retried with longer backoff,
as rejected credentials can not be fixed by retrying, to avoid locking the account.
@varmar05
varmar05 requested a review from MarcelGeo October 6, 2026 11:57
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant