Describe the bug
Since commit c5bf3ad ("Fail closed instead of auto-downgrading, and back up config to a writable path under the hardened update unit"), backup_existing() in install.sh falls back to $INSTALL_DIR/config-backups (e.g. /opt/pulse/config-backups) when the config directory's parent isn't writable, which is always the case under the hardened pulse-update.service sandbox (ProtectSystem=strict).
ensure_config_backup_headroom() correctly checks free disk space before creating a new backup, but nothing ever prunes old snapshots after a successful update — the only cleanup path is the rm -rf on a failed cp -a. As a result, every unattended update run (daily via pulse-update.timer, plus any manual restart that triggers a fresh config backup) adds another full timestamped snapshot under config-backups/, each roughly the size of the whole config directory, and none are ever removed.
On a small LXC root filesystem (8GB), config-backups/ grew to 2.1GB across just 5 snapshots in 3 days, filling the disk and causing service instability. This will affect any systemd/LXC install running unattended updates.
To reproduce
- Install Pulse on an LXC container with the hardened pulse-update.service (or any setup where /etc is read-only for the update unit).
- Let pulse-update.timer run for a few days (or manually invoke an update/restart multiple times).
- Observe $INSTALL_DIR/config-backups accumulating one full snapshot per run with no removal of old ones.
Expected behavior
After a successful update (or on each backup_existing() call), prune config-backups/ to keep only the N most recent snapshots (e.g. ls -1t | tail -n +N+1 | xargs -r rm -rf --), similar to how the disk-full/space-filling issue was previously fixed for the old /etc/pulse.backup.* path.
Pulse version
v5.1.36
Agent version
v5.1.36
Image tag or digest
N/A (native LXC install via install.sh, not a Docker image)
Installation type
ProxmoxVE LXC
Relevant logs or diagnostics
Proxmox LXC (unprivileged), Debian-based, Pulse installed via install.sh, auto-updates enabled (daily 2-6 AM window).
Confirmations
Describe the bug
Since commit c5bf3ad ("Fail closed instead of auto-downgrading, and back up config to a writable path under the hardened update unit"), backup_existing() in install.sh falls back to $INSTALL_DIR/config-backups (e.g. /opt/pulse/config-backups) when the config directory's parent isn't writable, which is always the case under the hardened pulse-update.service sandbox (ProtectSystem=strict).
ensure_config_backup_headroom() correctly checks free disk space before creating a new backup, but nothing ever prunes old snapshots after a successful update — the only cleanup path is the rm -rf on a failed cp -a. As a result, every unattended update run (daily via pulse-update.timer, plus any manual restart that triggers a fresh config backup) adds another full timestamped snapshot under config-backups/, each roughly the size of the whole config directory, and none are ever removed.
On a small LXC root filesystem (8GB), config-backups/ grew to 2.1GB across just 5 snapshots in 3 days, filling the disk and causing service instability. This will affect any systemd/LXC install running unattended updates.
To reproduce
Expected behavior
After a successful update (or on each backup_existing() call), prune config-backups/ to keep only the N most recent snapshots (e.g. ls -1t | tail -n +N+1 | xargs -r rm -rf --), similar to how the disk-full/space-filling issue was previously fixed for the old /etc/pulse.backup.* path.
Pulse version
v5.1.36
Agent version
v5.1.36
Image tag or digest
N/A (native LXC install via install.sh, not a Docker image)
Installation type
ProxmoxVE LXC
Relevant logs or diagnostics
Confirmations