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

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

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

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

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

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

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

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

hier kannst du effektiver checken

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

VG Tschortschi

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

Hallo Tschortschi,

aktuell bekomme ich folgendes Ergebnis vom laufenden DC:

free -h
              total        used        free      shared  buff/cache   available
Mem:           2,2G        1,2G        147M         27M        900M        865M
Swap:          7,9G         55M        7,8G

Der Server läuft seit etwas mehr als 5 Tagen.

top zeigt das folgende Ergebnis! Der Speicherverbrauch sortiert nach Prozess ist sehr sprunghaft:

top - 21:50:01 up 5 days,  2:36,  1 user,  load average: 0,20, 0,10, 0,09
Tasks: 172 total,   4 running, 167 sleeping,   0 stopped,   1 zombie
%Cpu(s):  9,9 us,  4,2 sy,  0,0 ni, 85,3 id,  0,0 wa,  0,0 hi,  0,5 si,  0,0 st
KiB Mem : 61,9/2301264  [||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||                                      ]
KiB Swap:  0,7/8241148  [|                                                                                                   ]

  PID USER      PR  NI    VIRT    RES    SHR S %CPU %MEM     TIME+ COMMAND
 1221 root      20   0 3376904  50700  17372 S  2,6  2,2  31:52.55 slapd
62969 root      20   0   40160   7268   4280 R  1,6  0,3   0:00.03 univention-moun
  743 root      20   0  747488  88460  32784 S  1,1  3,8   6:17.96 named
62959 root      20   0   38008   3504   2936 R  1,1  0,2   0:00.42 top
    1 root      20   0  205268   7468   5256 S  0,5  0,3   3:09.90 systemd
  419 message+  20   0   47308   3536   3072 S  0,5  0,2   1:43.84 dbus-daemon
  428 root      20   0   38096   4556   3960 S  0,5  0,2   1:49.70 systemd-logind
 1782 root      20   0 1368092  54960   4692 S  0,5  2,4  15:38.63 univention-mana
54632 root      20   0  689236  26268  14364 S  0,5  1,1   2:50.44 samba
62201 root      20   0       0      0      0 S  0,5  0,0   0:00.80 kworker/0:2
62966 root      20   0  107996   6468   5524 S  0,5  0,3   0:00.01 cron
62967 root      20   0  107996   6468   5524 S  0,5  0,3   0:00.01 cron
62968 root      20   0  107996   6468   5524 S  0,5  0,3   0:00.01 cron
62970 root      20   0   21140   5140   3120 R  0,5  0,2   0:00.01 univention-moun
62971 root      20   0   21532   5444   3160 R  0,5  0,2   0:00.01 univention-moun
63060 root      20   0  689228  29348  17580 S  0,5  1,3  10:09.61 samba
    2 root      20   0       0      0      0 S  0,0  0,0   0:00.03 kthreadd
    3 root      20   0       0      0      0 S  0,0  0,0   0:26.65 ksoftirqd/0
    5 root       0 -20       0      0      0 S  0,0  0,0   0:00.00 kworker/0:0H
    7 root      20   0       0      0      0 S  0,0  0,0   1:22.72 rcu_sched
    8 root      20   0       0      0      0 S  0,0  0,0   0:00.00 rcu_bh
    9 root      rt   0       0      0      0 S  0,0  0,0   0:00.00 migration/0
   10 root       0 -20       0      0      0 S  0,0  0,0   0:00.00 lru-add-drain
   11 root      rt   0       0      0      0 S  0,0  0,0   0:01.21 watchdog/0
   12 root      20   0       0      0      0 S  0,0  0,0   0:00.00 cpuhp/0
   13 root      20   0       0      0      0 S  0,0  0,0   0:00.00 kdevtmpfs
   14 root       0 -20       0      0      0 S  0,0  0,0   0:00.00 netns
   15 root      20   0       0      0      0 S  0,0  0,0   0:00.22 khungtaskd
   16 root      20   0       0      0      0 S  0,0  0,0   0:00.00 oom_reaper
   17 root       0 -20       0      0      0 S  0,0  0,0   0:00.00 writeback
   18 root      20   0       0      0      0 S  0,0  0,0   0:00.00 kcompactd0
   19 root      25   5       0      0      0 S  0,0  0,0   0:00.00 ksmd

Als gegenbeispiel der Status des hängenden DC, wiederhergestellt aus einem Snapshot:
free -h

top
[m]

Ich habe noch eine weitere VM komplett frisch als DC installiert jedoch noch nicht aktiviert. Diese verhält sich ebenfalls ähnlich! Es wird Swap Speicher genutzt obwohl dies erst ab 60% Speicherbelegung statt finden sollte! Aktuell werden fast 60% genutzt.

Die Installation von htop klappt nicht. Ich habe es aber auch noch nicht weiter versucht!

Vg
Hendrik

Na wenn die Maschinen nur 1,7GB haben wundert mich gar nichts. Das ist arg wenig.

Hallo Moritz,

hier die Ausgabe auf dem aktiven DC:

root@DC:~# grep '^memory' /proc/cgroups
memory  3       717     1
root@DC:~# grep pam_systemd /etc/pam.d/common-session
session    optional   pam_systemd.so
root@DC:~# ucr get pam/session/systemd
root@DC:~# univention-check-templates
WARNING: The following UCR files are modified locally.
Updated versions will be named FILENAME.dpkg-*.
The files should be checked for differences.

/etc/univention/templates/files/etc/nagios/nrpe.cfg

Hier das Ergebnis auf dem neu installierten Testserver:

root@testdc:~# grep '^memory' /proc/cgroups
memory  9       155     1
root@testdc:~# grep pam_systemd /etc/pam.d/common-session
root@testdc:~# ucr get pam/session/systemd
root@testdc:~# univention-check-templates

Vielen Dank & Vg

Hendrik

Hallo SirTux,

das alte Setup lief über Monate mit 1,25GB für den DC und teilweise mit deutlich weniger für andere Server.
Ich habe die Kapazität in unterschiedlichen Test mehr als verdoppelt bis zu 4GB und dennoch kommt es zum einfrieren der VM, es dauert nur länger bis es passiert!
Die VM bekommt auch nicht ganz langsam immer mehr Probleme bis sie eben nur schlecht reagiert, der Speicherplatz steigt innerhalb kürzester Zeit sprunghaft an bis die Maschine nicht mehr nutzbar ist!
Es hilft nur ein Hardreset!

Sorry wenn ich das hier so schreibe aber hier läuft sogar Windows erhebleich zuverlässiger mit 4GB und einem installierten AD, DNS, DHCP und hat immer noch Platz für irgendwelchen Management Schnickschnack plus GUI und was sonst so niemand braucht wie AV…!

Bei mir derzeit absolut undenkbar!

Vg
Hendrik

Jup, es handelt sich in der Tat um den Kernel-cgroup-Bug, der durch pam_systemd getriggert wird. Siehe hier für Abhilfe.

Zu wenig Speicher für die VM ist definitiv nicht das Problem.

Moin zusammen,
der Bug ist nicht mit der Version UCS 4.4 Errata 191 behoben.
Wir sind bei 4.4.2 Errata 319 und haben das Problem aktuell auch.

Es kann gut sein, dass pam_systemd noch in common-session aktiv ist, aus welchem Grund auch immer. Poste die Ausgabe von

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

Hallo Moritz,

Danke für den Link. Ich werde das heute Abend testen und gebe dann entsprechend Rückmeldung!

Vg
Hendrik

Hallo Moritz,
hier die Ausgaben:

root@:~# grep ‘^memory’ /proc/cgroups
memory 7 165 1
root@:~# grep pam_systemd /etc/pam.d/common-session
#session optional pam_systemd.so
root@:~# ucr get pam/session/systemd
root@:~# univention-check-templates
root@:~#

Vielen Dank für deinen Einsatz :grinning:

@MarcelBlock Dein Problem ist ein anders. Eröffne dafür bitte einen eigenen Thread; es bringt nichts, unterschiedliche Themen im selben Thread zu behandeln.

@hendrix3er Falls deine Installation bereits neu genug ist, kann es evtl. auch schon reichen, die common-session neu schreiben zu lassen und anschließend zu testen, ob pam_systemd wirklich auskommentiert ist:

ucr commit /etc/pam.d/common-session
grep pam_systemd /etc/pam.d/common-session

Sobald’s auskommentiert ist, musst du den Server trotzdem einmal rebooten, um den bereits geleakten Speicher im Kernel wieder loszuwerden.

Salve Hendrix,

der Moritz hat da mehr Ahnung als ich. Das was er schreibt klingt gut…
Ein UCS Linux Guru halt :slight_smile:

Schöne WE Euch allen…

VG Tschortschi

Hallo,

das Problem scheint gelöst! Allerdings wird die Swap Disk immer noch recht schnell beschrieben!
Leider musste ich den Server nach 6 Tagen wegen einer Stromumschaltung abschalten. In sofern liefen die VMs nur 5 Tage bis zur Abschaltung!

Vielen Dank Moritz und allen Anderen für die Hilfe!

Vg
Hendrik