/run/lock kommen an Obergrenze - Debian 8 + Plesk Onyx

[GwenDragon]

Auf einem dedizierten Server ist Onyx unter Debian 8 installiert.
/rum/lock ist auf einem Root-Server tmpfs mit einer max. Größe von 5 MB.

Aus irgendeinem Grund ist /run/lock ab ca. 06:30 zu 100% voll.
Eindeutig Dateigröße, nicht Inodes wie mit df zu sehen.
Der Bösewicht ist SharedLockManagerStorage0.2.3:
root@sv ~ # l /run/lock/lmlib/SharedLockManagerStorage0.2.3
-rw-rw-rw- 1 root root 8.0M Dec 18 10:04 /run/lock/lmlib/SharedLockManagerStorage0.2.3

Das führt dazu dass AIDE mit SIGBUS/SEGV abstürzt und der tägliche Check per cron nicht mehr abläuft. Auch fail2ban streikt danach.

Ist das schon bei euch vorgekommen? Wie löst ihr das Problem?

 

[XioniX]

Bei mir unter Arch noch nicht vorgekommen, da sind die tmpfs alle 50% Ramgröße. Debian hat wohl wirklich eine Defaultgröße von 5MB. Da sich Onyx wohl nicht an die Prinzipien von /run/lock hält und da megabyteweise Files ablegt hast du nur 2 Möglichkeiten: Onyx wegschmeissen oder die tmpfs size auf einen sinnvolleren Wert erhöhen unter /etc/default/tmpfs.

 

[GwenDragon]

So wie das aussieht benutzt Debian 8 systemd und das ignoriert die /etc/default/tmpfs.

Nur wie kann ich dann LOCK_SIZE setzen? Welcher Service ist dafür zuständig?

 

[XioniX]

Ich würde (laut "man tmpfs") einfach ein /run/lock Eintrag in /etc/fstab anlegen und den Debian Bug reporten.

 

[GwenDragon]

So wie ich das sehe, ist sw-server von Onyx der Bösewicht.
Der greift sich während der morgendlichen crons mehr als das voreingestellte Debian-Limit von 5MB bei /run/lock.
Und dann fällt einiges auf die Nase.

Ich jetzt in der fstab für /run/lock auf size=1% hoch gesetzt.

# changeed to bigger size to workaround full locks
tmpfs /run/lock tmpfs rw,nosuid,nodev,noexec,relatime,size=1% 0 0

Und siehe da, es klappt.