Docker auf vServer: cannot allocate memory: unknown

[bens86]

Hallo,
seit zwei Tagen kämpfe ich mit einem sehr eigenartigen Verhalten auf einem vServer bei 1blu (Ubuntu 20.04):
Ohne irgendeine Komponente upgedated zu haben erhalte ich beim Versuch einen Docker Container zu deployen folgenden Fehler:

Cannot start service nginx-proxy: OCI runtime create failed: container_linux.go:367:
starting container process caused: process_linux.go:340: applying cgroup configuration for process caused:
mkdir /sys/fs/cgroup/memory/docker: cannot allocate memory: unknown

Meine Vermutung, an Docker kann es nicht liegen denn ein mkdir in /sys/fs/cgroup/memory/ führt unmittelbar zum selben Fehler. Das System wurde auch bereits neu aufgesetzt, Fehler bleibt bestehen. Speicher ist jedoch genug vorhanden, System war ja komplett frisch.

Meine Recherchen führten mich unter anderem zu diesen Seiten:
https://github.com/docker/for-linux/issues/841
https://translate.google.com/translate?hl=&sl=zh-CN&tl=en&u=https://zhuanlan.zhihu.com/p/106757502

Demnach hat es wohl bei manchen geholfen einen Kernelparameter zu setzen: cgrop.memory=nokmem
Aber kann ich das einfach bei einem vServer setzen? Die Verifikation über cat /proc/cmdline legt irgendwie nahe, dass er sich für den Parameter nicht interessiert.

Ich hoffe jemand hat eine Idee.

 

[d4f]

Aber kann ich das einfach bei einem vServer setzen?

In der Annahme dass es ein paravirtualisierter vServer (KVM, Vmware, ...) ist, virtualisiert die Umgebung einen vollen Rechner inklusive Bios und damit Bootloader. Entsprechend kannst du eigene Kernelmodule oder -parameter verwenden.

Die Verifikation über cat /proc/cmdline legt irgendwie nahe

Wie genau hast du die Parameter definiert? Einmalig im Bootpozess per vKVM in Grub oder über die Konfiguration?

as System wurde auch bereits neu aufgesetzt, Fehler bleibt bestehen. Speicher ist jedoch genug vorhanden, System war ja komplett frisch.

Eigeninstallation oder Template? Bei Templates gibt es manchmal sehr skurrile Voreinstellungen zur host-seitigen Optimisierung.
Der Anbieter verwendet ja nicht zufällig auch noch Memory Ballooning (dass RAM grösser werden kann)?

Demnach hat es wohl bei manchen geholfen einen Kernelparameter zu setzen: cgrop.memory=nokm

Beachte dass du damit eine Container-Funktionalität ausschaltest. Dies ist hauptsächlich relevant falls die Container von Dritten bedient werden.

Was sagen folgende Werte, insbesondere der Dritte?
/sys/fs/cgroup/memory/memory.limit_in_bytes
/sys/fs/cgroup/memory/memory.max_usage_in_bytes
/sys/fs/cgroup/memory/memory.failcnt

 

[bens86]

In der Annahme dass es ein paravirtualisierter vServer (KVM, Vmware, ...) ist, virtualisiert die Umgebung einen vollen Rechner inklusive Bios und damit Bootloader. Entsprechend kannst du eigene Kernelmodule oder -parameter verwenden.

Virtuozzo kommt hier zum Einsatz. Daher wohl auch keine Möglichkeit die Kernel Parameter zu überschreiben oder?

Wie genau hast du die Parameter definiert? Einmalig im Bootpozess per vKVM in Grub oder über die Konfiguration?

Hatte es über Grub versucht zu definieren, aber zieht dann wohl wegen der Virtualisierung nicht. Gibts ne alternative Möglichkeit um das in meinem Szenario zu setzen? Ist die Alternative sonst nur eine Virtualisierung mit KVM?

Eigeninstallation oder Template? Bei Templates gibt es manchmal sehr skurrile Voreinstellungen zur host-seitigen Optimisierung.
Der Anbieter verwendet ja nicht zufällig auch noch Memory Ballooning (dass RAM grösser werden kann)?

Ein fertiges Template.

Was sagen folgende Werte, insbesondere der Dritte?
/sys/fs/cgroup/memory/memory.limit_in_bytes
/sys/fs/cgroup/memory/memory.max_usage_in_bytes
/sys/fs/cgroup/memory/memory.failcnt

/sys/fs/cgroup/memory/memory.limit_in_bytes: 25769803776
/sys/fs/cgroup/memory/memory.max_usage_in_bytes: 985370624
/sys/fs/cgroup/memory/memory.failcnt: 0

 

[d4f]

Virtuozzo kommt hier zum Einsatz. Daher wohl auch keine Möglichkeit die Kernel Parameter zu überschreiben oder?

Virtuozzo ist mittlerweile nicht mehr Synonym mit OpenVZ, sondern eine Softwaresuite welche unter anderem auch KVM-Paravirtualisierung unterstützt. Es ist quasi die Konkurrenz zu Proxmox mit ähnlichem Funktionsumfang.
Sprich - Paravirtualisierung ist möglich, hängt davon ab was tatsächlich bei dir im Einsatz ist. Einfachste Rätellösung, führe das hier aus;

hostnamectl | fgrep Chassis

Wenn der Name "container" enthält ist es LXC, OpenVZ oder ähnliches, ansonsten ist es "vm" bei Paravirtualisierung/Emulierung.
Will heissen, wenn da vm steht funktioniert der boot parameter sofern korrekt angewandt.

/sys/fs/cgroup/memory/memory.failcnt: 0

In der Annahme dass es eine VM ist, weiss der Kernel nichts vom Fehler. Seltsam! Gibt "dmesg" dir weiteren Aufschluss?

 

[bens86]

Wenn der Name "container" enthält ist es LXC, OpenVZ oder ähnliches, ansonsten ist es "vm" bei Paravirtualisierung/Emulierung.
Will heissen, wenn da vm steht funktioniert der boot parameter sofern korrekt angewandt.

hostnamectl | fgrep Chassis
Chassis: container

In der Annahme dass es eine VM ist, weiss der Kernel nichts vom Fehler. Seltsam! Gibt "dmesg" dir weiteren Aufschluss?

Das ist alles was dmesg sagt:

[4352070.700907] device veth0d9bf19 entered promiscuous mode
[4352070.709283] device vethba80d13 entered promiscuous mode
[4352070.768805] device vethba80d13 left promiscuous mode
[4352070.811639] device veth0d9bf19 left promiscuous mode

Bleibt mir jetzt nur die Virtualisierung über KVM?

 

[d4f]

Chassis: container

Autsch. Dass Anbieter noch immer auf Kosten ihrer Kunden Geld sparen wollen....
Kann ich dir einen vernünftigen VPS-Hoster ans Herz legen welcher nicht auf Container-Technik basiert? Bspw PHP-Friends? https://php-friends.de/vserver-ssd