Container System hängt sich auf

[BigBen]

Hallo,

in der aktuellen Proxmox Version 4.x wurde ein Container System mit Debian-System installiert.

Es laufen bereits mehrere Container Systeme mit Debian bislang fehlerfrei.

Bei einem dieser Container kommt es des öfteren vor, dass es nicht mehr reagiert.

In solch einem Fall kann man sich nicht mehr über die Konsole anmelden. Im Proxmox-Monitor wird angezeigt, dass die CPU-Auslastung gleich 0 ist.

Bislang habe ich leider noch keinen Ansatzpunkt gefunden, um die Fehlerquelle eingrenzen zu können.

Hat schon jemand eine ähnliche Situation gehabt?

pveversion -v liefert folgende Ausgabe:

proxmox-ve: 4.3-66 (running kernel: 4.4.19-1-pve)
pve-manager: 4.3-3 (running version: 4.3-3/557191d3)
pve-kernel-4.4.6-1-pve: 4.4.6-48
pve-kernel-4.4.13-1-pve: 4.4.13-56
pve-kernel-4.2.6-1-pve: 4.2.6-36
pve-kernel-4.4.8-1-pve: 4.4.8-52
pve-kernel-4.4.13-2-pve: 4.4.13-58
pve-kernel-4.2.8-1-pve: 4.2.8-41
pve-kernel-4.4.16-1-pve: 4.4.16-64
pve-kernel-4.4.19-1-pve: 4.4.19-66
pve-kernel-4.4.10-1-pve: 4.4.10-54
lvm2: 2.02.116-pve3
corosync-pve: 2.4.0-1
libqb0: 1.0-1
pve-cluster: 4.0-46
qemu-server: 4.0-91
pve-firmware: 1.1-9
libpve-common-perl: 4.0-75
libpve-access-control: 4.0-19
libpve-storage-perl: 4.0-66
pve-libspice-server1: 0.12.8-1
vncterm: 1.2-1
pve-qemu-kvm: 2.6.2-2
pve-container: 1.0-78
pve-firewall: 2.0-31
pve-ha-manager: 1.0-35
ksm-control-daemon: 1.2-1
glusterfs-client: 3.5.2-2+deb8u2
lxc-pve: 2.0.5-1
lxcfs: 2.0.4-pve1
criu: 1.6.0-1
novnc-pve: 0.5-8
zfsutils: 0.6.5.7-pve10~bpo80

 

[fireon]

Hi,

ja leider oder besser gesagt gut das ich das Verhalten noch nicht kenne Was hast du denn in dem Container laufen, also was für Applikation? Bitte auch die Config:

pct config <ID>

Kannst du dich bei dem Verhalten auch nicht mehr direkt vom Host verbinden? Also z.B.

pct enter <ID>

 

[BigBen]

Hallo,

den Befehl pct kenne ich noch nicht.

hier mal die Configuration:

arch: amd64
cpulimit: 2
cpuunits: 1024
hostname: WebServer
memory: 1024
mp0: local:800/vm-800-disk-2.raw,mp=/mnt/webserver,size=40G
mp1: /mnt/clh-net-share,mp=/mnt/clh-net-share
net0: bridge=vmbr0,hwaddr=66:36:63:35:31:31,ip=dhcp,ip6=dhcp,name=eth0,type=veth
onboot: 1
ostype: debian
rootfs: local:800/vm-800-disk-1.raw,size=10G
swap: 1024

Auf dem System läuft Debian Jessie mit einem nginx Webserver. An sich nichts besonderes.

Ein zweiter Kandidat, bei dem es auch gerne hin und wieder auftrtt ist dieser:

arch: amd64
cpulimit: 2
cpuunits: 2048
hostname: hm-ccu2-historian
memory: 1024
net0: bridge=vmbr0,hwaddr=32:33:64:64:35:36,ip=dhcp,ip6=dhcp,name=eth0,type=veth
onboot: 1
ostype: debian
rootfs: local:122/vm-122-disk-1.raw,size=8G
swap: 512

Auf diesem System läuft lediglich ein Backup-Service, der regelmäßig Daten von einer Quelle in eine postgre-Datenbank wegschreibt. Das geschieht nur einmal am Tag. In meinem Augen auch nichts besonderes.

Wenn es das nächste mal wieder hängt, werde ich versuchen, mit dem obigen Befehl von Proxmox auf das System zuzugreifen.

LG, BigBen

 

[fireon]

Sieht eigentlich ganz gut aus. Kann nichts böses entdecken. Geht event. aus was für einem Grund auch immer der RAM aus? Die Ramanzeige in PVE was LXC Mem angeht stimmt manchmal nicht ganz. Hast ein Nagios oder ein CheckMK laufen?

 

[BigBen]

Nagios bzw. Icinga lief mal Dadurch dass man jedes einzelne Service von einem Host händisch einpflegen muss, war der Aufwand einfach zu groß geworden. Letzendlich ist noch eine undefinierbarer Fehlersituation aufgetreten; danach lief nichts mehr. An sich ist es eine gute Sache wenn diese nur ein wenig mehr intelligenter wären, was die Erkennung von Services und Hosts betrifft, das wäre super. Aber soetwas habe ich bislang nur im beruflichen Umfeld gesehen. Cisco bietet solch eine intelligentes Monitoring System für einen stolzen Preis an. Da braucht man nur noch einen Scan an schmeißen und schon findet es alle möglichen Hosts die gerade im LAN Umfeld sich befinden und deren Services und Eigenschaften. Im OpenSource Umfeld habe ich solch eine ähnliche umfassende Lösung noch nicht gefunden.

Nachtrag:
Zwischenzeitlich wurde der Arbeitsspeicher von Proxmox vergrößert. Wenn es am mangelndem Arbeitsspeicher gelegen haben sollte, dann müsste es nun nicht mehr auftreten.

Vorher waren 16 GB an RAM vorhanden. Nun sind es 32 GB. (weiter Aufstocken geht leider nicht)
In Proxmox laufen 5 Debian CTs, die je. max 2 GB RAM zugewiesen bekommen haben.

 

[fireon]

Ok, dann warten wir mal ab.

Es gibt ein Projekt das heist Check_MK. Gibt es für alle Distris zum Download. Man braucht in der Bedienung keine Linuxkenntisse und sämtliche Services (würde jetzt mal behaupten 95%) werden automatische gefunden und mit den fast immer richtigen Schwellenwerten eingetragen. Das ist ein Segen wenn man Nagios hatte. Teste es, du wirst überzeugt sein. Hier mal ein Auszug im Anhang.

 

[BigBen]

Hallo fireon,

Check_mk lässt sich anscheinend nicht so leicht installieren.

Bei der Installation wurde gemäß dieser Anleitung verfahren: https://mathias-kettner.de/cms_omd_basics.html

Dennoch wird beim Aufruf der Webseite angezeigt, dass die Site nicht gestartet sei:

OMD: Site Not Started
You need to start this site in order to access the web interface.

Es wurde eine Site mit dem Namen myNet erstellt und anschließend gestartet:

$ omd start myNet
Starting rrdcached...OK
Starting npcd...OK
Starting nagios...OK
Starting dedicated Apache for site myNet...OK
Starting Nagios Service Check Acceptor...OK
Starting xinetd...OK
Initializing Crontab...OK

Dennoch scheint etwas zu fehlen.

 

[fireon]

Hmm, ok kann ich jetzt nicht nachvollziehen. Hatte vor ein paar Wochen Checkmk auch auf Debian LXC ohne Probleme. Auf Centos7 tuts nicht und auf Ubuntu 16.04 auch kein Problem. Kannst du in die Instanz rein? Also "su mynet"? Event. Groß-Kleinschreibung. Also doch "myNet"...

Erstell zum Test doch noch eine Instanz und poste hier den gesamten Output. "omd create home"

Ansonsten wende dich bitte an die Mailingliste: "Mailinglist Check_MK" <checkmk-de@lists.mathias-kettner.de>