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:
co-authored by
Claude Opus 5
parent
ea98d1b556
commit
a47551724b
@@ -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
|
||||
|
||||
Reference in New Issue
Block a user