LXC schaltet einfach ab

D

djdonnerwolke

Active Member
Sep 26, 2020
59
10
28
35
Hallo miteinander,

Ich habe zuhause einen Wireguard in einem LXC Container laufen.
Hostname: sv19-wireguard
ID: 119

Nun ist es so, dass die Kiste um 11:54:06 Uhr einfach abgeschaltet hat.

Mitbekommen habe ich dies dann über mein Monitoring als Push.
Die Kiste läuft gut, ich nutze sie gerade viel, da ich im Kurzurlaub bin und meinen ganzen Traffic übers Hotel-WLAN via VPN nach Hause schicke.

Ich habe nun in der Syslog vom Proxmox Host reingeschaut und auch in der des LXCs.
Das was ich auf dem Host an Informationen gefunden habe hilft mir nicht wirklich weiter. Ich würde gerne wissen wollen, warum die Kiste einfach aus geht. Nachdem ich dann ca 20 nach 12 auf mein Handy geschaut habe, hab ich den Container wieder eingeschaltet. Er läuft wieder. Ohne Probleme.

Frage an euch:
Wo kann ich noch nachgucken?
Ich habe natürlich auch in die Auth.log geguckt, aber da ist nichts auffälliges zu erkennen. Das Monitoring meldet sich halt jede Minute einmal an um den Zustand zu Prüfen. (zu meiner Verteidigung: ich habe erst vor ein paar Tagen auf SNMP umgestellt^^)

Ich hänge hier noch Screenshots an. Vielleicht geben die etwas Aufschluss.

Wäre klasse, wenn sich vielleicht doch noch jemand findet, der ein wenig was sagen kann.

Vielen Dank und einen schönen Sonntag an alle! :)
 

Attachments

  • Screenshot_20221002-122224_JuiceSSH.png
    Screenshot_20221002-122224_JuiceSSH.png
    391.3 KB · Views: 22
  • Screenshot_20221002-132046_JuiceSSH.png
    Screenshot_20221002-132046_JuiceSSH.png
    348 KB · Views: 22
  • Screenshot_20221002-132133_JuiceSSH.png
    Screenshot_20221002-132133_JuiceSSH.png
    361.1 KB · Views: 21
Wenn die Platte vom Container nicht voll ist, dann zu wenig RAM.

Als gern-Optimierer habe ich festgestellt, dass 96MB RAM zwar toll aussehen, aber u.a. Nachts erheblich mehr benötigt wird (gerade wenn Backups laufen) und mir der Container dann um die Ohren fliegt.
 
bytegetter said:
Wenn die Platte vom Container nicht voll ist, dann zu wenig RAM.

Als gern-Optimierer habe ich festgestellt, dass 96MB RAM zwar toll aussehen, aber u.a. Nachts erheblich mehr benötigt wird (gerade wenn Backups laufen) und mir der Container dann um die Ohren fliegt.
Click to expand...
Hmm.
Die Kiste hat von mir 512MB RAM bekommen.
1664893035569.png

Mein Monitoring hat folgendes aufgezeichnet:
1664893174271.png
Das letzte Backup lief am 23.09.2022 morgens um 1 Uhr_:
1664893241211.png

Ich habe aber auch kein Problem der Maschine 1GB anstelle von 512MB zu geben. (?)
 
Last edited:
Wenn es ein normaler Container ist steht normalerweise im Log, wieso er den gekillt hat.

Z.B.:

Code: 
[17706688.024743] oom-kill:constraint=CONSTRAINT_MEMCG,nodemask=(null),cpuset=ns,mems_allowed=0,oom_memcg=/lxc/10700,task_memcg=/lxc/10700/ns/init.scope,task=systemd,pid=2031393,uid=100000
[17706688.024754] Memory cgroup out of memory: Killed process 2031393 (systemd) total-vm:99996kB, anon-rss:2272kB, file-rss:0kB, shmem-rss:0kB, UID:100000 pgtables:88kB oom_score_adj:0
[17706688.029410] oom_reaper: reaped process 2031393 (systemd), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB

Was sagt denn dmesg am Host?
 
bytegetter said:
Wenn es ein normaler Container ist steht normalerweise im Log, wieso er den gekillt hat.

Was sagt denn dmesg am Host?
Click to expand...
Code: 
[Sun Oct  2 11:54:03 2022] fwbr119i0: port 2(veth119i0) entered disabled state
[Sun Oct  2 11:54:03 2022] device veth119i0 left promiscuous mode
[Sun Oct  2 11:54:03 2022] fwbr119i0: port 2(veth119i0) entered disabled state
[Sun Oct  2 11:54:03 2022] audit: type=1400 audit(1664704448.903:12240): apparmor="STATUS" operation="profile_remove" profile="/usr/bin/lxc-start" name="lxc-119_</var/lib/lxc>" pid=1019091 comm="apparmor_parser"
[Sun Oct  2 11:54:04 2022] fwbr119i0: port 1(fwln119i0) entered disabled state
[Sun Oct  2 11:54:04 2022] vmbr0: port 6(fwpr119p0) entered disabled state
[Sun Oct  2 11:54:04 2022] device fwln119i0 left promiscuous mode
[Sun Oct  2 11:54:04 2022] fwbr119i0: port 1(fwln119i0) entered disabled state
[Sun Oct  2 11:54:04 2022] device fwpr119p0 left promiscuous mode
[Sun Oct  2 11:54:04 2022] vmbr0: port 6(fwpr119p0) entered disabled state
[Sun Oct  2 12:08:58 2022] audit: type=1400 audit(1664705344.002:12241): apparmor="DENIED" operation="mount" info="failed flags match" error=-13 profile="lxc-128_</var/lib/lxc>" name="/run/systemd/unit-root/" pid=1066236 comm="(ionclean)" srcname="/" flags="rw, rbind"
[Sun Oct  2 12:17:19 2022] loop1: detected capacity change from 0 to 16777216
[Sun Oct  2 12:17:19 2022] EXT4-fs (loop1): mounted filesystem with ordered data mode. Opts: (null). Quota mode: none.
[Sun Oct  2 12:17:19 2022] audit: type=1400 audit(1664705845.267:12242): apparmor="STATUS" operation="profile_load" profile="/usr/bin/lxc-start" name="lxc-119_</var/lib/lxc>" pid=1092832 comm="apparmor_parser"
[Sun Oct  2 12:17:20 2022] vmbr0: port 6(fwpr119p0) entered blocking state
[Sun Oct  2 12:17:20 2022] vmbr0: port 6(fwpr119p0) entered disabled state
[Sun Oct  2 12:17:20 2022] device fwpr119p0 entered promiscuous mode
[Sun Oct  2 12:17:20 2022] vmbr0: port 6(fwpr119p0) entered blocking state
[Sun Oct  2 12:17:20 2022] vmbr0: port 6(fwpr119p0) entered forwarding state
[Sun Oct  2 12:17:20 2022] fwbr119i0: port 1(fwln119i0) entered blocking state
[Sun Oct  2 12:17:20 2022] fwbr119i0: port 1(fwln119i0) entered disabled state
[Sun Oct  2 12:17:20 2022] device fwln119i0 entered promiscuous mode
[Sun Oct  2 12:17:20 2022] fwbr119i0: port 1(fwln119i0) entered blocking state
[Sun Oct  2 12:17:20 2022] fwbr119i0: port 1(fwln119i0) entered forwarding state
[Sun Oct  2 12:17:20 2022] fwbr119i0: port 2(veth119i0) entered blocking state

Ich hoffe du fängst was damit an. :)
 
bytegetter said:
Der Ausfall war doch am 27./28.09., oder? Von da bräuchte man dann auch das log.
Click to expand...
Nein, der Ausfall war am Sonntag, den 2. Oktober.
Am 27/28. War zwar auch ein Fehler, aber das hat nichts mit dem Ausfall zu tun. Da ging es eher um Berechtigungen, die ich angepasst hatte. Da konnte das Monitoring nicht auf die Maschine zugreifen.
 
bytegetter said:
Mach mal bitte:
Code: 
dmesg -H
Click to expand...
Sorry, bin hier noch nicht so bewandert :)

Code: 
[Oct 2 08:38] audit: type=1400 audit(1664692744.004:12233): apparmor="DENIED" operation="mount" info="failed flags match" error
:
 ESCESCOOBB
[  +0.398911] vmbr0: port 6(fwpr119p0) entered blocking state
:
 ESCESCOOBB
[  +0.000003] vmbr0: port 6(fwpr119p0) entered disabled state
:
 ESCESCOOBB
[  +0.000082] device fwpr119p0 entered promiscuous mode
:
 ESCESCOOBB
[  +0.000035] vmbr0: port 6(fwpr119p0) entered blocking state
:
 ESCESCOOBB
[  +0.000001] vmbr0: port 6(fwpr119p0) entered forwarding state
:
 ESCESCOOBB
[  +0.004169] fwbr119i0: port 1(fwln119i0) entered blocking state
:
 ESCESCOOBB
[  +0.000003] fwbr119i0: port 1(fwln119i0) entered disabled state
:
 ESCESCOOBB
[  +0.000105] device fwln119i0 entered promiscuous mode
:
 ESCESCOOBB
[  +0.000045] fwbr119i0: port 1(fwln119i0) entered blocking state
:
 ESCESCOOBB
[  +0.000002] fwbr119i0: port 1(fwln119i0) entered forwarding state
:
 ESCESCOOBB
[  +0.004023] fwbr119i0: port 2(veth119i0) entered blocking state
:
 ESCESCOOBB
[  +0.000003] fwbr119i0: port 2(veth119i0) entered disabled state
:
 ESCESCOOBB
[  +0.000056] device veth119i0 entered promiscuous mode
:
 ESCESCOOBB
[  +0.033650] eth0: renamed from vethBbqAei
:
 ESCESCOOBB
[  +0.388086] audit: type=1400 audit(1664705846.095:12243): apparmor="DENIED" operation="mount" info="failed flags match" error :
 ESCESCOOBB
=-13 profile="lxc-119_</var/lib/lxc>" name="/dev/shm/" pid=1093003 comm="(sd-mkdcreds)" fstype="ramfs" srcname="ramfs" flags="r :
 ESCESCOOBB
w, nosuid, nodev, noexec"
:
 ESCESCOOBB
[  +0.068908] audit: type=1400 audit(1664705846.163:12244): apparmor="DENIED" operation="mount" info="failed flags match" error :
 ESCESCOOBB
=-13 profile="lxc-119_</var/lib/lxc>" name="/run/systemd/unit-root/proc/" pid=1093034 comm="(networkd)" fstype="proc" srcname=" :
 ESCESCOOBB
proc" flags="rw, nosuid, nodev, noexec"
:
 ESCESCOOBB
[  +0.026852] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
:
 ESCESCOOBB
[  +0.000036] fwbr119i0: port 2(veth119i0) entered blocking state
:
 ESCESCOOBB
[  +0.000002] fwbr119i0: port 2(veth119i0) entered forwarding state
:
 ESCESCOOBB
[  +0.007858] audit: type=1400 audit(1664705846.199:12245): apparmor="DENIED" operation="mount" info="failed flags match" error :
 ESCESCOOBB
=-13 profile="lxc-119_</var/lib/lxc>" name="/run/systemd/unit-root/proc/" pid=1093040 comm="(resolved)" fstype="proc" srcname=" :
 ESCESCOOBB
proc" flags="rw, nosuid, nodev, noexec"
:
 ESCESCOOBB
[  +0.054602] audit: type=1400 audit(1664705846.255:12246): apparmor="STATUS" operation="profile_load" label="lxc-119_</var/lib :
 ESCESCOOBB
/lxc>//&:lxc-119_<-var-lib-lxc>:unconfined" name="lsb_release" pid=1093042 comm="apparmor_parser"
:
 ESCESCOOBB
[  +0.003138] audit: type=1400 audit(1664705846.255:12247): apparmor="STATUS" operation="profile_load" label="lxc-119_</var/lib :
 ESCESCOOBB
/lxc>//&:lxc-119_<-var-lib-lxc>:unconfined" name="nvidia_modprobe" pid=1093043 comm="apparmor_parser"
:
 ESCESCOOBB
[  +0.000005] audit: type=1400 audit(1664705846.255:12248): apparmor="STATUS" operation="profile_load" label="lxc-119_</var/lib :
 ESCESCOOBB
/lxc>//&:lxc-119_<-var-lib-lxc>:unconfined" name="nvidia_modprobe//kmod" pid=1093043 comm="apparmor_parser"
:
 ESCESCOOBB
[  +0.008621] audit: type=1400 audit(1664705846.263:12249): apparmor="STATUS" operation="profile_load" label="lxc-119_</var/lib :
 ESCESCOOBB
/lxc>//&:lxc-119_<-var-lib-lxc>:unconfined" name="/usr/lib/NetworkManager/nm-dhcp-client.action" pid=1093044 comm="apparmor_par :
 ESCESCOOBB
ser"
:
 ESCESCOOBB
[  +0.000007] audit: type=1400 audit(1664705846.263:12250): apparmor="STATUS" operation="profile_load" label="lxc-119_</var/lib :
 ESCESCOOBB
/lxc>//&:lxc-119_<-var-lib-lxc>:unconfined" name="/usr/lib/NetworkManager/nm-dhcp-helper" pid=1093044 comm="apparmor_parser"
:
 ESCESCOOBB
[  +0.000003] audit: type=1400 audit(1664705846.263:12251): apparmor="STATUS" operation="profile_load" label="lxc-119_</var/lib :
 ESCESCOOBB
/lxc>//&:lxc-119_<-var-lib-lxc>:unconfined" name="/usr/lib/connman/scripts/dhclient-script" pid=1093044 comm="apparmor_parser"
:
 ESCESCOOBB
[Oct 2 12:38] kauditd_printk_skb: 8 callbacks suppressed
:
 
Dann muss unter /var/log irgendwo ein Hinweis darauf zu finden sein, ausser die Platte vom Host war zu dem Zeitpunkt voll.
 
Platte vom Host war nicht voll. Habe noch ~18GB frei und die Platte, auf der die VMs/LXC liegen, hat auch noch ein paar 100GB frei.
In /var/log hatte ich schon geguckt. Aber scheinbar nicht an richtiger Stelle.
Wo kann ich denn noch nachgucken?
Vielen dank für deine Zeit!
 
Bisher sehe ich im Log nur ein paar Fehler wegen dem womöglich fehlenden Nesting.

Probiere mal für den Container Nesting zu aktivieren.

Sehen die anderen hier im Forum noch etwas, was ich bisher übersehen habe?
 
  • Like
Reactions: djdonnerwolke
Ich hab gestern erfahren, dass der neue Kernel auf dem Proxmox in Verbindung mit den Wireguard in einem LXC Probleme machen soll.
Aber nur aus dritter Hand mitbekommen, noch nichts gelesen.
Das Nesting habe ich jedenfalls mal aktiviert.

Es war für mich das erste mal, dass die Kiste unkontrolliert herunterfährt bzw einfach abschaltet.
Ich werde es in der nächsten Zeit mehr beobachten.

Falls jemand trotzallem noch was dazu einfällt, immer gern her damit.
Vlg und einen schönen Abend.
 
Guten Morgen,

heute früh hat sich die sv19 wieder abgeschaltet.
Nesting hatte ich gestern Abend aktiviert.
Hinzu kommt, dass ich auf dem Proxmox Webinterface keine Infos mehr zu meinen VMs angezeigt bekomme
(Sieht dann gleich aus wie HIER.)
 
Welche Version hast du denn von Proxmox laufen?

Was sagt die Auslastung von Proxmox?

Aus Erfahrung werden Container wegen vollem RAM oder Dateisystem beendet. Scheinbar läuft zu dem Zeitpunkt was anderes voll.

Was läuft denn sonst noch auf dem Host was viele Resourcen benötigt?
 
Eigentlich habe ich nicht viel Last auf dem Server.

1664951321344.png

Es lief auch kein Backup Job oder sonstiges.
Aktuell habe ich die 7.2-11 installiert aber es steht eigentlich ein Neustart aus, damit der neue Kernel geladen würde.
 
bytegetter said:
Hatte der Reboot eine Änderung gebracht?
Click to expand...
Guten Morgen,
um es kurz zu machen: Nein.
Es gehen sogar andere Maschinen sterben, es bleibt nicht bei dieser einen.
Was mir aber aufgefallen ist: Vorher scheint der Prozess
Code: 
pvestatd
nicht zu funktionieren.
Der Prozess stürzt aus irgendwelchen Gründen ab. Und dann irgendwann geht halt ein LXC einfach aus.
Das sieht dann genau so aus wie HIER.
 
You must log in or register to reply here.

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Quick Navigation

Home Get Subscription Wiki Downloads Proxmox Customer Portal About

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!
Community platform by XenForo® © 2010-2024 XenForo Ltd.
Top Bottom