Jep DietPi hat standardmäßig /var/log als tmpfs mount. Wir überschreiben allerdings stündlich die logs mit einem leeren redirect: > /var/log/beispiel.log
Das tmpfs war früher standardmäßig 20 MiB groß, aber in der Tat war das in seltenen Fällen nicht genug, sodass wir den Standard auf 50 MiB erhöht haben. Ich meine sogar das war wegen Pi-hole, aber müsste da noch mal die alten issues durchforsten.
Ein kleiner Hinweise kommt von dem was wir früher mit der /var/log/pihole.log gemacht haben. Ich meine das war früher die einzige query log (?) und die sollte natürlich nicht stündlich geleert werden. Deshalb hatten wir diese log speziell behandelt: Sie wurde nicht stündlich sondern nur täglich geleert. Das hat wohl in seltenen Fällen nicht gereicht, sodass wir sie zusätzlich komplett geleert haben, falls sie über 1/3 der tmpfs Größe (also über ~17 MiB) erreicht hatte. Mit anderen Worten es kam vor, dass pihole.log an einem Tag 17 MiB überschritten hat, womöglich weit, sodass die 50 MiB von allen logs zusammen erreicht wurden, was natürlich zu Fehlermeldungen und evtl. ausfallenden Prozessen geführt hat. Aber das sind natürlich extreme Ausnahmefälle bei sehr großen Clientzahlen.
- Aber, da die query logs, welche im web UI einsehbar sind, nun in einer gesonderten Datenbank gespeichert werden, kann
pihole.log im Prinzip deaktiviert werden, und sollte es im Falle von RAMlog auch: pihole -l off
Generell, da tmpfs den erlaubten Speicher nicht sofort voll belegt, sondern es nur eine Obergrenze ist, kannst du das ruhig erst mal schön groß wählen, halt so dass es nicht gerade nicht zu OOM Kills führen kann.
Schraube definitiv an den /etc/logrotate.d/ Konfigurationen, verringere die maximale Anzahl an gespeicherten Rotationen, erhöhe evtl. die Rotationsintervalle etc, je nachdem wie groß welche Logdateien so werden. Selbes gilt für log verbosity Einstellungen der einzelnen Programme, wo möglich.
Und falls du rsyslog oder einen anderen syslog daemon installiert hast, du jedoch systemd als init-system nutzt (systemctl), lösche den syslog daemon, e.g.: apt purge rsyslog
Mit systemd ist ohnehin immer systemd-journald aktiv, abrufbar über journalctl (z.B. journalctl -u pihole-FTL), sodass plain text syslogs nicht zusätzlich nötig sind, sondern nur doppelt gemoppelt (und wegen /var/log/syslog + /var/log/daemon.log + /var/log/message sogar teils dreifach und mehr...). systemd-journald logs werden standardmäßig ebenfalls im RAM gehalten.
Und noch etwas:
Verlege /var/tmp definitiv nicht ins RAM! Der FHS entsprechend ist es für Dateien welche einen Reboot überleben sollen, und damit rechnen viele Programme. /tmp hingegen ist für Dateien vorgesehen, welche den Reboot nicht überleben müssen, aber dieses ist schon standardmäßig ein tmpfs mount. Nur im Falle eines R/O Systems macht das Sinn, allerdings wäre dann ein overlayfs konsequenter.