FAILED: active sessions prevent maintenance

[cirrusflyer]

I'm seeing this message and not sure what it means.

FAILED: active sessions prevent maintenance

Thanks

[cirrusflyer]

Looks like I need to use "break-lock" to clear this.

[cirrusflyer]

Looks like that didn't work.

[m3nu]

It means that the repo can't be compacted if other write sessions are there. We support parallel writes, but not for maintenance.

If you don't actively write and compact from annother machine, this is likely an old session and we should tighten locking a bit. I'll see if this situation can arise in theory.

[cirrusflyer]

Thanks. This is running a Synology NAS under Docker. Running the break-lock doesn't find anything. Is there anything else I can do?

[m3nu]

Pending sessions should resolve themselves. I'll also trace the issue and see if something can be improved.

[m3nu]

I tracked this down to session markers being refreshed only as part of backup upload/write progress, while maintenance currently waits up to 72 hours before considering a session stale. In cases like container restarts, kill -9, stalled uploads, or PID/hostname changes across Docker runs, a dead backup can leave behind a fresh-looking sessions/<id>.json marker that blocks compact, prune, and other maintenance commands.

The fix plan is to make backup sessions heartbeat independently of upload progress, reuse the existing session guard lifecycle, and reduce the stale-session threshold to the same 45-minute rule already used for pending-index recovery. I'm also making session refresh non-resurrecting, so a refresh thread cannot recreate a marker after it has been removed, and improving the ActiveSessions error so it includes host/pid/age plus a clearer remediation hint.

[m3nu]

Fixed via 2c7a393