Server hängt sich seit Update auf UCS 4.4-0 243 in unregelmäßigen Abständen auf

UCS - Univention Corporate Server
#1

Hallo,

seitdem ich das Update auf UCS 4.4-0 durchgeführt habe, frieren alle aktulisierten Server in unregelmäßigen Abständen ein unabhängig voneinander ein. Der eingefrorene Server ist via Ping erreichbar allerdings ist der Server nicht via http oder SSH erreichbar. Eine lokale Anmeldung in der Console scheint im ersten Moment möglich, nachdem ich den Benutzernamen eingegeben habe dauert es aber sehr lange bis zur Passwortabfrage nach dieser passiert dann für mehrere Stunden nichts mehr.
Bisher habe ich den Server dann hart ausgeschaltet, er funktioniert dann für einige Tage wieder unauffällig bis das Problem erneut auftritt.
Eine Überprüfung der Logs zeigt, dass der Server irgendwann einfach aufhört irgendetwas zu tun. Ich habe keine nennenswerten Auffälligkeiten gefunden außer, dass der letzte Logfile Eintrag mehrere Stunden alt ist. Gewöhnlich werden auch Informationen in regelmäßigen Abständen geloggt!

Aktuell ist der DC eingefroren und es geht nichts mehr. Ich werde heute Abend einen Snapshot vom Server anfertigen ehe ich ihn resete, dann kann ich die VM jederzeit wieder im aktuellen Zustand restoren um weitere Analysen durchzuführen!

Ist ein solches Verhalten generell schon einmal aufgetreten in der betreffenden UCS Version?
Vielen Dank im Vorraus!

Vg
Hendrik

Hello,

since my last update I have done to version 4.4-0, the server is freezing in irregular intervals. The Server responds to ping but https requests or SSH doesn’t work anymore!
A local console login seems to be working but after the username prompt it needs a few minutes to present the password prompt. After this I had waiting some hours before I hard turned the VM off. After a reboot the VM works without problems for 1 or 2 days. Than the same problem occure again!
I have checked the log files but it seems that the server stop logging when the problem occures.

At this moment the DC is frozen and the whole environment is down and not reachable!
Today at the evening I will create a VM snapshot. Than I can restore this VM in it’s current state for further analyses!

Is there a known problem it can occure such a problem?
Thank you in advanced!

/BR
Hendrik

#2

Hallo,
hat vielleicht der Vmhost ein problem ? Da ich nicht weiß was du als Blech einsetzt kann ich nur vermuten.
Möglicherweise hat der Vmhost ein Festplatten oder Speicherproblem

Beste Grüße
pider

#3

Hallo pider,

vielen Dank für Deine Antwort. Auf dem Blech finde ich keine Auffälligkeiten zumal hier noch diverse weitere VMs laufen die allesamt keine Probleme haben, sich allerdings noch auf einem älteren UCS Versionsstand befinden. Es betrifft tatsächlich ausschließlich die aktualisierten VMs.
Ich habe gestern festgestellt, dass der hängen gebliebene Server dieses Mal über den gesamten Zeitraum geloggt hat. Ich habe also hoffentlich eine Basis aus der möglicherweise Fehlermeldungen hervorgehen. Aus zeitlichen Gründen bin ich jedoch noch nicht zu einer vollständigen Analyse gekommen. In der Datei /var/log/syslog habe ich fast im Sekundentakt Meldungen gefunden welche allerdings auf den ertsen Blick eine geringe Aussagekraft haben.
Zum Zeitpunkt des Fehlers gab es jedoch eine Fehlermeldung bez. Docker!

Kannst Du mir eventuell Tipps geben in welchen Logs ich am ehesten fündig werde?

Ich möchte noch erwähnen, dass die Umgebung eine gewachsene VM Landschaft ist. Erstellt nur für den Privatgebrauch mit damals eher geringen Linux Kenntnissen speziell im Bezug auf Univention.
Im Laufe der Zeit gab es auch einige Fehler die mir unterlaufen sind. Ich habe sie zwar immer wieder ausbügeln können auch Dank der Mithilfe hier im Forum aber ich kann auch nicht ausschließen, dass es sich bei meinem Problem nicht um einen Folgefehler handelt der zuvor einfach nur nicht aufgefallen war.

Vielen Dank!

Vg
Hendrik

#4

Ich würde die üblichen verdächtigen /var/log/dmesg,messages.log,kern.log,docker.log schauen ob dort was interressantes geloggt wird.

#5

Hallo,

ich habe mir die Logs mal angeschaut. Die meisten Logs welche aussagekräftig sein sollten wurde die protokollierung leider mit auftreten des Problems beendet. Aus dem Log file /etc/var/auth.log geht aber hervor, dass der Server den auf ihm selbst laufenden LDAP Dienst nicht mehr erreichen konnte.
Auf den anderen Servern welche bislang abgestürzt waren sieht es zu den jeweiligen Zeitpunkten genau so aus. Ansonsten sehen die Logs weitgehend unauffällig auf (mal abgesehen von Fehlern die schon seit längerer Zeit auftreten).

Die Server laufen alle etwa 2 bis 4 Tage, dann bleiben sie hängen!
Heute hatte ich das Glück im Pech, dass mein Monitoring Server (Nagios) mal wieder hängen geblieben ist. Ich hatte allerdings die Möglichkeit mich mit sehr viel Geduld am Server anzumelden.

Hier viel mir dann auf, dass der Prozess kswapd0 eine durchgehend erhöhte CPU Last anzeigt.
Dies bewog mich dazu mir die Swap Disk anzusehen. Hierbei viel mir auf, dass alle aktualisierten Server die Swap Disk vollschreiben obwohl der RAM Speicher teilweise nicht einmal bis zur Hälfte belegt ist.

Ursprünglich habe ich die Swap Disk nur als Sicherheit angelegt. Soll heißen: den RAM jeder VM habe ich knapp aber so groß gestaltet, dass die SWAP Disk möglichst nicht benötigt wird. Dies hatte ich sporadisch manuell getestet und habe meistens festgestellt, dass die SWAP Disk meistens gar nicht oder nur zu wenigen KB,sehr selten mehrere Megabyte, deutlich unter 100MB, benötigt wird und das auch dann, wenn die VM Wochenlang lief.
Mittlerweile wird die SWAP Disk von allen aktualisierten Systemen zu mehrern 100MB bis 2GB genutzt und das nach 1 bis 2 Tagen!

In diesem Zusammenhang habe ich mir den DC noch einmal angesehen. Nachdem dieser das erste Mal nach etwa 3 Tagen abstürzte hatte ich den Speicher erhöht, seitdem stürzt der Server etwa alle 4 Tage ab!
Auf dem Hypervisor konnte ich feststellen, dass die Disklast teilweise sehr hoch liegt. Das deckt sich mit meiner Beobachtung als ich vor dem Server stand denn das RAID leuchtete wie ein Weihnachtsbaum.
Allerdings die übrigen nicht betroffenen VMs liefen zwar spübar träger, aber sie liefen (Anmeldung via SSH funktionierte, Kommandos wurde ausgeführt).

Eine Prüfung des SWAP-Disk files aller VMs aus dem Backup hat gezeigt, dass diese nach dem Update deutlich angewachsen sind.

Ich habe mir den, im Betriebszustand gesicherten DC wieder hergestellt und habe ihn in einer Testumgebung weiterlaufen lassen.
Die Anmeldung war ähnlich träge wie gestern, SWAP mit fast 1GB belegt, dass habe ich hier zuvor nie gesehen. Der Dienst kswapd0 ist permanent bei hoher CPU Last.

Ich frage mich wie und unter welchen Umständen die SWAP Disk befüllt wird. Vor dem Update scheinbar nur wenn der RAM Speicher wirklich voll lief, seit dem Update beginnt das System (der Demon kswadd0) offenbar nicht benötigte Blöcke auszulagern und irgendwann wird es dann zu viel. Das System wird extrem träge - es hängt in meiner Wahrmehmung!

Ich habe unter anderem den folgenden Artikel hierzu gefunden:
https://uberubuntu.info/questions/5158/kswapd0-nimmt-viel-cpu-auf

Vg
Hendrik

#6

Hallo,

ich habe nun den RAM für alle betreffenden VMs erhöht. Momentan sieht es gut aus, die SWAP Disk wird derzeit nicht gefüllt. Allerdings ist der nun reservierte Speicher je VM in Bezug auf die Nutzung ziemlich hoch!
Zusätzlich habe ich den Parameter vm.swappiness auf 75% gesetzt.

Ich beobachte das jetzt für ein paar Tage und melde mich dann mit einem Ergebnis.

Vg
Hendrik

#7

Danke für dein ausführliches Update. Bin gespannt ob das die Lösung ist.
Beste Grüße
pider

#8

Hallo,

erste Rückmeldung seit der Anpasung der RAM Speicherkapazität.
Die Server laufen nun seit 4 Tagen. Heute ist der BDC hängen geblieben.
Wenn ich das richtig sehe ist für den DC morgen am Dienstag Abend mit einem Absturz zu rechnen.

Eine Prüfung der Swap Disk zeigt auf allen betroffenen Systemen bereits wieder eine intensive Nutzung.
Bisher scheint das Problem also nicht gelöst zu sein außer ich erschlage jede VM mit Speicherplatz.

Vg
Hendrik

#9

Guten morgen!

Heute morgen haben sich die nächtsen zwei Server zerlegt! Ein rebooten war nicht möglich bzw. hing ebenfalls. Nach 3 Stunden habe ich die VMs hart ausgeschaltet! Es handelte sich um den Nagios und einen Proxy.
In allen Fällen das gleiche Bild. Der Speicher ist nahezu aufgebraucht, die Swap Disk zu etwa 50% belegt.
Hochgerechnet muss ich für jede VM etwa 16 bis 32 GB planen damit sie hoffentlich einen Monat absturzfrei läuft. Zuvor konnten es auch mal Monate sein ohne dass ein Neustart nötig gewesen wäre!

Es sieht fast so aus, als ob sich das OS beginnt selbst zuzumüllen. Beim nächsten Mal versuche ich mal die einzelnen Prozesse zu prüfen.

Eine Frage am Rande! Wieviele Postgres instanzen sollten auf einem DC laufen?

Vg
Hendrik

#10

Salve Hendrik,

was für einen Server Hardware setzt du als Host für deine VMs ein?

Welcher Hyper kommt zum Einsatz?

Raid Controller?

Ich hatte in der Vergangenheit ein seltsames verhalten bei einem Acronis Backup und hier waren Bad Blocks im Virtual Volume schuld… hatte gedauert bis ich dahintergekommen bin.

Also das ist jetzt mal nur so eine Idee

Vg Tschortschi

#11

Hallo Tschortschi,

bei dem Server handelt es sich um einen Fujitsu Primary TX120 S3, der RAID Controller ist ein LSI… irgendein Hardware RAID Controller. Ich habe das ganze aber auch auf einem anderen Blech getestet ohne Unterschied!
Bei dem Hypervisor handelt es sich um (ich traue es mich kaum zu sagen) HyperV Server 2012R2. Hintergrund ist die Kompatibilität!

Ich vermute das Problem tatsächlich innerhalb des OS denn es trifft ausschließlich VMs welche geupdated wurden. Alle anderen haben kein Problem. Selbst wenn ich eine der Problem VMs restore zur vorversion ist das Problem beseitigt. Nach Installation der Updates geht das beschriebene Problem sofort von vorne los!
Wenn ich die aktualisierte VM auf einem anderen Blech einspiele (ältere Hardware mit HyperV 2012 ohne RAID) habe ich ebenfalls das gleiche Problem.

Gibt es von Univention eigentlich irgendwo Empfehlungen zur Speichergröße?
Irgendwie bin ich bisher nicht fündig geworden…

Vielen Dank & Vg
Hendrik

#12

Hello i this is a problem… i only see this post now, because it is in english… but why now?

Well today i update all my servers to latest updates (4.4-2 errata301) in the morning, the main DC just HANG without reason, only the ssh session that i have open to each command reports

-bash: fork: Cannot allocate memory

The Dc is a ESXI Vm, after hard reset everything appear ok, then start search in the forum and find this post.

I leave here some pics.
image
image
image

This server is running for amost 4 years… the VM settings are always the same

I think @hendrix3er is right… something in the updates is causing issues with memory and swap… this VM never used swap disk and as the image show… today something happen

#13

Hallo Hendrik,

wie gesagt war nur eine Idee… Ich selbst hab ESXi bei jedem meiner Kunden. Dort laufen UCS Installationen mit Kopano und Nextcloud.

Das Update habe ich auch bei jedem am vergangenen Wochenende Installiert. Bis jetzt kann ich nichts feststellen. Das macht mir ja schon bisschen Angst was du da schreibst :blush:

Hier in der Doku steht am Anfang

„Je nach geplantem Einsatzzweck und der Benutzeranzahl variieren die Systemanforderungen sehr stark. Mindestanforderungen für die Installation sind 1 GB Arbeitsspeicher und 8 GB Festplattenspeicher.“

https://docs.software-univention.de/quickstart-de.html#quickstart:intro

Schau mal hier steht was über deinen Microsoft Hyper-V

https://wiki.univention.de/index.php/Cool_Solution_-_Installing_UCS_in_Microsoft_Hyper-V

Denke das ist ein Fall für die Jungs von UCS!?

Vg Tschortschi

#14

Hello codemind,

thank you for your response and sorry for the delay! It seems we have exactly the same problem. At the moment it seems that my DC is working now but I have added lots of RAM capacity compared with the formerly scenario. Nevertheless i have the feeling that the system near to run into the problem again. Sometimes if I do any action on the server, I can see that the available capacity will be shrunk dramatically! For example I restart a service and I can see the available ram capacity will be reduced from 500MB to less than 50MB. Than I get back most capacity but not 500MB as before. Eventually I expect the DC shoud stop working after 5 days. Now it runs more than 7.5 days but i see the available RAM capacity is further shrunken.
The whole RAM capacity of the DC is 2.2GB before it was 1.25GB. The number of simultanusly used accounts are 2 Kopano accounts with authentication to the DC, thats it!

Meanwhile I noticed that the server runs into the problem too if it is completely isolated from each external connectivity. This means, turn the system on in it’s own area, wait and the system runs into this problem by it self! No user is connected, no other server, no internet, nothing but only loged in via text console! It looks there, that the server needs 2.2GB RAM at minimum only for running! Of course internal cron jobs are running!

/BR
Hendrik

#15

Hallo Tschortschi,

vielen Dank! Ich habe, abgesehen vom Hypervisor nahezu das gleiche Setup! Bisher läuft mein DC noch. Ich habe allerdings das Gefühl, dass ich mir Betriebszeit über RAM erkaufen muss. Die benötigte Kapazität wird dann je nach Bedarf gigantisch und übersteigt die Mindestanforderungen deutlich.

Vielleicht kannst (oder solltest) Du bei Deinem Kunden einfach nur mal prüfen ob sich die RAM Verwaltung anders verhält als zuvor.

Vielen Dank besonders auch für die Links. Der zweite war mir noch nicht bekannt, zum ersten habe ich mir mehr Infos bezüglich der Anforerungen erhofft!

Vg
Hendrik

#16

Hallo Hendrik, bis jetzt ist alles noch normal… es steht aber wieder ein update aus… vielleicht behebt das dein Problem…Bin gespannt was da rauskommt. Dann noch gutes Gelingen… bis da hin

VG Tschortschi

#17

Hallo Tschortschi,

haben die VMs denn genügend RAM? Mir scheint, wenn ich meine VMs mit reichlich RAM versorge kommt es nicht zu einem Problem bez. es beginnt entsprechend verzögert! Ich denke mal mit 4 - 8GB RAM sollte die VM dann einige Monate laufen. Bis dahin ist die Chance auf einen Neustart ohnehin relativ hoch!
Das Update hatte ich am Freitag eingespielt! Am Samstag morgen hatte ich fast 100 neue Mails da der DC nicht mehr erreichbar war! Den reboot habe ich nach über zwei Stunden abgebrochen in dem ich die VM hart ausgeschaltet habe!
Seitdem läuft sie erstmal wieder aber offenbar muss ich die VMs alle paar Tage nachts rebooten da sie so für den Dauerbetrieb nicht geeignet sind und das in einer Kleinstumgebung!
Ich habe zu Testzwecken einen aktuellen DC aufgesetzt mit nur 1.2GB RAM. Auch dieser läuft langsam voll! Da diese VM jedoch nichts tut als zu laufen, denke ich, das wird sich noch hinziehen ehe auch diese VM abstürzt! (Das ganze erinnert mich ein wenig an Windows 98)

Vg
Hendrik

#18

Salve Hendrix,
melde dich mal mit ssh an der Maschine an und poste mal was da kommt

free -h
und dann mach mal den Befehl top danach m drücken… die Prozesse nach Speicherbedarf

mein Speicher einer meiner Maschine sieht so aus
root@mailmx:~# free -h
total used free shared buff/cache available
Mem: 7,8G 2,2G 2,9G 90M 2,6G 5,2G
Swap: 6,8G 0B 6,8G

mal sehen ob ich dir da helfen kann…
VG Tschortschi

#19

Was mir noch eingefallen ist. Installiere dir mal das tool „htop“ nach.

hier kannst du effektiver checken

https://wiki.ubuntuusers.de/htop/

VG Tschortschi

#20

Wird auf dem Server evtl. noch pam_systemd benutzt? Führ doch bitte mal die folgenden Befehle aus & zeig ihre Ausgabe:

grep '^memory' /proc/cgroups
grep pam_systemd /etc/pam.d/common-session
ucr get pam/session/systemd
univention-check-templates
Mastodon