[Feature] LOG_DISK_SIZE default too small for Proxmox/Ceph hosts

[Blecherer]

LOG_DISK_SIZE default too small for Proxmox/Ceph hosts

Summary

The default log2ram configuration uses:

LOG_DISK_SIZE=256M

This value is too small for hardened Proxmox VE hosts running additional services such as Ceph, auditd, process accounting (acct) and Netdata.

Environment

• PegaProx Hardened Proxmox VE 9
• 2-node HA cluster
• Ceph
• Netdata
• auditd
• acct (process accounting)
• RAM: 377 GiB

What happened

After several days of normal operation, /var/log filled up completely:

Filesystem      Size  Used Avail Use%
/dev/zram0      224M  219M     0 100%

Netdata warned about /var/log for several hours before the filesystem became full.

Eventually Proxmox started reporting:

No space left on device
closing file '/var/log/pve/tasks/active.tmp.xxxxx' failed

The HA manager then marked one HA resource as failed:

service vm:108 (error)

The VM could no longer be started or migrated until the HA error flag was manually cleared.

Root cause

The main log consumers were:

• /var/log/account (acct process accounting)
• auditd
• journald
• Proxmox task logs

All of these are enabled by the PegaProx hardening profile.

Workaround

Increasing

LOG_DISK_SIZE=2G

followed by a reboot solved the issue.

Afterwards:

Filesystem      Size  Used Avail Use%
/dev/zram0      2.0G  238M  1.6G  14%

No further "No space left on device" errors occurred.

Suggestion

Instead of using a fixed value of 256M, consider one of the following:

• choose LOG_DISK_SIZE dynamically based on installed roles (Ceph, HA, etc.)
• increase the default for server installations (e.g. 1–2 GiB)
• document that hosts with Ceph/auditd/acct should increase LOG_DISK_SIZE

This would prevent HA failures caused by a full /var/log filesystem while keeping the benefits of log2ram.

[mkellermann97]

Thanks — well documented, and that failure chain (full /var/log → PVE task-log write fails → vm:108 error) is a genuinely nasty one. To set expectations first: PegaProx doesn't ship or set log2ram / LOG_DISK_SIZE anywhere, so the 256M is log2ram's own stock default on your host rather than a value we control. What is on us: the hardening profile enables auditd and process accounting (acct), which add real /var/log volume — so backing /var/log with a 256M zram while running audit/acct (plus Ceph/Netdata) is exactly the squeeze you hit, and your bump to 2G is the right call. I'll get this into the hardening docs (if /var/log is on log2ram/zram and you enable audit/acct, size it to ≥1–2G), and I'm flagging two profile-side tweaks for us to weigh — cap journald (SystemMaxUse) and bound pacct rotation — so the footprint our profile adds stays predictable. No code change yet, since that touches the hardening profile and needs testing on a real node. If PegaProx is useful to you, opencollective.com/pegaprox keeps these improvements coming. — Marcus

[Blecherer]

Thanks for the clarification! That makes sense. I didn't realize the 256M came from log2ram itself rather than PegaProx. One additional observation from our testing: The full /var/log didn't just generate warnings. It also caused a Proxmox HA resource to enter the error state because PVE could no longer write task files (No space left on device). Even after increasing the zram size and rebooting, the HA resource had to be manually recovered (ha-manager set vm:108 --state disabled before it could be started again). So from an operational perspective, the impact is larger than just "logs filling up"―it can affect HA resource availability. I think documenting this for installations using auditd/acct together with log2ram would be very valuable.

…

________________________________ Von: mkellermann97 ***@***.***> Gesendet: Montag, 29. Juni 2026 12:35 An: PegaProx/project-pegaprox ***@***.***> Cc: Micha ***@***.***>; Author ***@***.***> Betreff: Re: [PegaProx/project-pegaprox] [Feature] LOG_DISK_SIZE default too small for Proxmox/Ceph hosts (Issue #595) [https://avatars.githubusercontent.com/u/257130705?s=20&v=4]mkellermann97 left a comment (PegaProx/project-pegaprox#595)<#595 (comment)> Thanks ― well documented, and that failure chain (full /var/log → PVE task-log write fails → vm:108 error) is a genuinely nasty one. To set expectations first: PegaProx doesn't ship or set log2ram / LOG_DISK_SIZE anywhere, so the 256M is log2ram's own stock default on your host rather than a value we control. What is on us: the hardening profile enables auditd and process accounting (acct), which add real /var/log volume ― so backing /var/log with a 256M zram while running audit/acct (plus Ceph/Netdata) is exactly the squeeze you hit, and your bump to 2G is the right call. I'll get this into the hardening docs (if /var/log is on log2ram/zram and you enable audit/acct, size it to ≥1C2G), and I'm flagging two profile-side tweaks for us to weigh ― cap journald (SystemMaxUse) and bound pacct rotation ― so the footprint our profile adds stays predictable. No code change yet, since that touches the hardening profile and needs testing on a real node. If PegaProx is useful to you, opencollective.com/pegaprox keeps these improvements coming. ― Marcus ― Reply to this email directly, view it on GitHub<#595?email_source=notifications&email_token=ADUJ2VFNTMYWLH2QBFQUCDD5CJBANA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOBTGE2DSNZXGUZKM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#issuecomment-4831497752>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ADUJ2VAMAFXWD7PTMA2MIZT5CJBANAVCNFSNUABGKJSXA33TNF2G64TZHMYTCMZWGYYDSNRVGU5US43TOVSTWNBXGY3DMMJXGU4DFILWAI>. Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS<https://github.com/notifications/mobile/ios/ADUJ2VHUPKQJSO22MAW3C7L5CJBANA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOBTGE2DSNZXGUZKM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KUZTPN52GK4S7NFXXG> and Android<https://github.com/notifications/mobile/android/ADUJ2VFMZUF4BTXQALW2AUL5CJBANA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOBTGE2DSNZXGUZKM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2K4ZTPN52GK4S7MFXGI4TPNFSA>. Download it today! You are receiving this because you authored the thread.Message ID: ***@***.***>

[mkellermann97]

Good point — the HA fallout is the real sting here, not the log warnings. A full /var/log taking out PVE's task-file writes and parking an HA resource in error (needing a manual ha-manager recovery) is exactly the second-order failure worth calling out, so I've folded that into the doc note: auditd/acct + log2ram sizing, plus what to do if an HA resource gets stuck afterwards. Appreciate you closing the loop on it. — Marcus