fix: make the Discord world reset actually delete the world

The reset script died on its very first line. log() piped through tee into
zomboid/logs/world-reset.log, that directory was owned by the container's
subuid, and the script runs as the podman user -- so tee returned EACCES and
set -e killed the run before it stopped the server or touched a save. Every
`@bot` reset since had been a no-op that reported nothing.

Nothing mounts zomboid/logs into a container; it only holds output from
host-side helpers running as the podman user, so it is now owned by that user
rather than by the subuid the container volumes need.

log() no longer treats the file as load-bearing either. stdout is already
captured by the journal, so an unwritable log is worth continuing past rather
than aborting a wipe over.

Verified end to end by writing the trigger exactly as the bot does: server
stopped, saves and player database deleted, service restarted.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
Bastian de Byl
2026-08-26 18:33:57 -04:00
co-authored by Claude Opus 5
parent ea98d1b556
commit a47551724b
3 changed files with 21 additions and 3 deletions
@@ -11,7 +11,12 @@ SAVES_PATH="{{ podman_home }}/.local/share/volumes/zomboid/data/Saves/Multiplaye
DB_PATH="{{ podman_home }}/.local/share/volumes/zomboid/data/db/${SERVER_NAME}.db"
log() {
echo "[$(date '+%Y-%m-%d %H:%M:%S')] $1" | tee -a "$LOGFILE"
local msg="[$(date '+%Y-%m-%d %H:%M:%S')] $1"
echo "$msg"
# stdout is already captured by the journal; the file is a convenience.
# Never let it be fatal -- an unwritable log used to abort the whole wipe
# on the very first line, under set -e.
echo "$msg" >> "$LOGFILE" 2>/dev/null || true
}
# Ensure XDG_RUNTIME_DIR is set for systemctl --user