Documented docker run stacks a new dump-dir bind mount on every engine start; a crash-loop reaches 32767 mounts and the engine can no longer start

Re-confirmed during 4.2 pre-release testing on master @ afcba6c1 (2026-09-08); first observed as "O2" in #738.

The documented engine docker run mounts /var/lib/dblab:/var/lib/dblab/:rshared and /var/lib/dblab/dblab_pool/dump:/var/lib/dblab/dblab_pool/dump. With rshared propagation, every engine (re)start doubles the host's mount stack on the dump directory. A crash-loop (here: a config with an unset ${SOURCE_DB_PASSWORD} placeholder + --restart unless-stopped, ~20 restarts) grows it exponentially:

# mount | grep -c /var/lib/dblab/dblab_pool/dump
32767
# docker start dblab_server
Error response from daemon: ... error mounting "/var/lib/dblab/dblab_pool/dump" ...: no space left on device

At that point the engine cannot start even after the config is fixed; the operator has to know to run while umount /var/lib/dblab/dblab_pool/dump; do :; done (one umount collapses the whole peer group). Normal operation also leaks: after ~5 restarts in this test run the dump dir had 7 stacked mounts, after ~15 it had 31.

Suggestions (any one is enough):

  • engine: on startup, detect a stacked bind mount on the dump dir and unmount the duplicates (or refuse with a clear message naming the fix);
  • docs/install: drop the nested dump-dir volume from the documented command when the parent is already rshared, or mount it :rslave;
  • local-install / docs: warn that --restart unless-stopped + a fatal config error leads here.