Post-Install: System

Settings post-install Proxmox

What this category covers

Six independent, system-level optimizations. They tune journald and logrotate to stop logs from filling the disk, raise kernel and file-descriptor limits so applications with many open files don't hit ceilings, balance memory for a virtualization host, add kexec for "reboots without the BIOS", and configure automatic recovery on kernel panic. All six are tracked and reversible from the Uninstall menu.

Optimize journald

Rewrites /etc/systemd/journald.conf with sane defaults so the systemd journal can't slowly eat your root partition, then restarts systemd-journald and vacuums existing logs.

Key values

  • Storage=persistent — keep logs on disk across reboots.
  • SystemMaxUse=64M / RuntimeMaxUse=60M — hard caps on journal disk/memory usage.
  • Compress=yes, Seal=no — compress logs, skip forward-secure sealing (saves CPU).
  • MaxLevelStore=info — store info and above (required for ProxMenux Monitor's log viewer and for Fail2Ban to detect SSH/Proxmox auth failures from the journal).
  • Rate-limits: 1000 events / 30 s to prevent log flooding.
  • ForwardToSyslog=no, ForwardToWall=no — don't duplicate messages to syslog or broadcast to consoles.

Why MaxLevelStore=info matters

Using a stricter level like warning makes ProxMenux Monitor's log viewer show nearly identical entries across all date ranges (because most activity is info-level), and it prevents Fail2Ban from seeing failed logins. If you want less log volume, rely on the SystemMaxUse cap and RateLimitBurst instead of lowering the stored level.

Optimize logrotate

Rewrites /etc/logrotate.conf with a tighter policy suitable for a host that's also part of an SSD-protecting Log2RAM setup: daily rotation, 7-day retention, 10 MB size trigger, compression, and copytruncate so active services keep writing without reopening their log files. Original logrotate.conf is backed up to .bak on first apply.

# /etc/logrotate.conf — ProxMenux-optimized
daily
su root adm
rotate 7
create
compress
size 10M
delaycompress
copytruncate

include /etc/logrotate.d

Log2RAM-friendly

The size 10M trigger means logs rotate on size or daily, whichever comes first. Combined with Log2RAM's RAM-backed /var/log, this keeps the working set small so flushes to disk stay cheap.

Increase various system limits

Raises a bunch of kernel, systemd and PAM limits that default to values too low for a host running many VMs, containers and networked services.

FileWhat it sets
/etc/sysctl.d/99-maxwatches.conffs.inotify.max_user_watches / max_user_instances / max_queued_events = 1048576
/etc/sysctl.d/99-maxkeys.confkernel.keys.maxkeys / root_maxkeys = 1000000
/etc/sysctl.d/99-swap.confvm.swappiness = 10, vm.vfs_cache_pressure = 100
/etc/sysctl.d/99-fs.conffs.nr_open / file-max = 2097152, fs.aio-max-nr = 1048576
/etc/security/limits.d/99-limits.confnofile and nproc to 1,048,576 (unlimited for root)
/etc/systemd/system.conf + user.confDefaultLimitNOFILE=1048576 for systemd services
/etc/pam.d/common-session + runuser-lsession required pam_limits.so so the above apply to login shells
/root/.profileulimit -n 1048576 for the root shell

Why inotify matters

Applications like Docker, Syncthing, Node.js watchers, Plex's library scanner and many more hit max_user_watches quickly. Default on Debian is 8192 — a single running Plex can exhaust it. 1M is generous and costs ~1 KB of RAM per watch, which is negligible.

Optimize memory settings

Writes a balanced sysctl profile to /etc/sysctl.d/99-memory.conf. Designed for a hypervisor host — prefers keeping VM working sets in RAM and frees pages proactively so allocation bursts don't stall.

# /etc/sysctl.d/99-memory.conf
vm.swappiness = 10               # Avoid swapping unless truly necessary
vm.dirty_ratio = 15              # Start writeback sooner (default 20)
vm.dirty_background_ratio = 5    # Start async writeback earlier (default 10)
vm.overcommit_memory = 1         # Allow overcommit (needed by many applications)
vm.max_map_count = 262144        # Enough for modern apps (ES, Docker, some games)
vm.compaction_proactiveness = 20 # Only on kernels that support it

swappiness=10 on memory-tight hosts

On a host with 16 GB RAM running many VMs, lowering swappiness can push the kernel to OOM-kill processes instead of swapping. If you're routinely seeing OOM events, raise swappiness back to 30–60 in /etc/sysctl.d/99-memory.conf after the script runs.

Enable fast reboots (kexec)

Installs kexec-tools and wires it up so you can reboot the host straight into a new kernel without going through BIOS/UEFI firmware. On big servers where POST takes 45 – 90 seconds, this turns a reboot from a coffee break into a few seconds of downtime.

What ProxMenux installs

  • Package kexec-tools (with debconf pre-answered so apt doesn't prompt during install).
  • Systemd unit /etc/systemd/system/kexec-pve.service — loads the Proxmox kernel and initrd into memory at boot, reusing the current cmdline.
  • An alias in /root/.bash_profile: reboot-quicksystemctl kexec.

Usage after the next reboot (or manual systemctl start kexec-pve):

reboot-quick           # kexec into the already-loaded kernel
# Equivalent:
systemctl kexec

When not to use kexec

kexec skips firmware-level init. If you rely on BIOS/UEFI to reset hardware state — for example, a GPU doing passthrough that only resets cleanly on full POST, or a troublesome HBA firmware — kexec reboots may leave those devices in a half-initialized state. Use a normal reboot after kernel upgrades or when you need BIOS/UEFI changes to take effect. reboot-quick is for everyday restarts.

Enable restart on kernel panic

Makes the kernel auto-reboot instead of sitting forever on a panic screen. Critical on headless/remote Proxmox hosts where a hung kernel means all your VMs are down until you can power-cycle the box.

# /etc/sysctl.d/99-kernelpanic.conf
kernel.core_pattern = /var/crash/core.%t.%p   # where to drop core dumps
kernel.panic = 10                             # reboot 10s after a panic
kernel.panic_on_oops = 1                      # oops → treated as panic
kernel.hardlockup_panic = 1                   # hard lockup → panic → reboot

Pair this with remote console access

Auto-reboot is a recovery mechanism, not a debug tool. If you want to investigate a panic rather than just come back up, use the kexec option above with the kernel kdump support (not configured by ProxMenux) or capture a serial console to another host before enabling auto-reboot.

Verification

After applying the System optimizations:

# journald: actual size in use and limit
journalctl --disk-usage

# logrotate: check config is active (no errors)
logrotate -d /etc/logrotate.conf 2>&1 | head -20

# System limits: check a few effective values
sysctl fs.inotify.max_user_watches fs.file-max vm.swappiness vm.dirty_ratio
ulimit -n     # inside a new root shell

# kexec: service enabled
systemctl is-enabled kexec-pve

# kernel panic config
sysctl kernel.panic kernel.panic_on_oops kernel.hardlockup_panic

Fully reversible

All six options are tracked in installed_tools.json, so they appear in Uninstall Optimizations if you want to back any of them out. Reverts restore the sysctl files' defaults, drop the systemd unit and alias for kexec, and reset journald/logrotate to stock Debian configs.

Related