amayer1983/docksentry v2.9.2

v2.9.2 — is your data directory somewhere that survives?

on GitHub

All of this comes out of #2 — @famewolf losing his settings over and over, and @NotRetarded asking a question about the log that turned out to be a fair complaint.

Docksentry checks whether its data directory is somewhere that survives

He lost his settings on a recreate. Then after a compose down/up. Then again. He restored from backup, reconfigured three hosts, and wrote: "I'm afraid to restart them." Every single time, all we told him was "possible data loss" — the symptom, and nothing else.

The cause was one line in his compose file:

- /mnt/dockerdata/docker/containers/docksentry/config:/app/data

We use /data. Nothing in this image has ever read /app/data. So his bind mount held nothing, and the real /data fell to the anonymous volume that our VOLUME ["/data"] creates — a fresh one for every container, discarded with the old one. Which is exactly why it "worked all this time" and then lost everything on every recreate: within one container's life the settings really were there.

All of that is visible from inside the container, in its own mounts. So it looks now, on startup, instead of describing the loss afterwards:

• a bind mount at a path we never read gets named, together with the corrected line to put in your compose file
• an anonymous volume at /data gets named, because it will not survive the next recreate — including the one a self-update does
• sockets, /etc/localtime and the documented /data/compose mount are left alone

The alert stopped crying wolf

Measured on a fresh install configured only through environment variables, across three boots: /data ends up holding version_state.json and nothing else, because save_persistent() only ever runs from a user action.

So anyone who drives Docksentry purely from their compose file has no settings.json, has lost nothing, and was being warned about possible data loss on every restart. The alarm was loudest for exactly the people with nothing to lose.

Whether settings were ever saved here is recorded now rather than guessed, with a marker written alongside every save. A real loss is still reported — in the log as well as your notification channels — and a first boot or an env-only install gets one quiet line instead. The marker is a plain file and never a setting, so nothing about it can end up outranking an environment variable.

Skipped (self): Docksentry left the ordinary log

@NotRetarded asked what was being skipped and why, which is the tell that a line is costing more attention than it is worth. Nothing was wrong: we keep our own container out of the regular update path because updating yourself through it kills PID 1 mid-swap. That bookkeeping sits behind DEBUG=true now.

The failure diagnostics stay unconditional on purpose. Stop …: effective_stop=60s, subprocess=90s came out of a debug-OFF log and is what made #2 readable at all — a diagnostic nobody has switched on is not a diagnostic.

Backups say which machine they came from

I backup 3 hosts to my pc currently and end up with this: […] No clue what host they are from.

The file carries your BOT_LABEL now, or the container hostname: docksentry-backup-dockmox.lan-20260816-152818.json. That matters more than tidiness — restoring the wrong one puts another machine's groups and pins on this one. Neither set, and you get the old name.

Nothing to do on upgrade. If your mount is wrong, this version says so on the first start.