V7: samba prozesse gehen durch (die Decke)

Tobias · 13. September 2020 um 20:43

Hi.
Seit ein paar Tagen habe ich samba-Prozesse, die sich irgendwie aufschaukeln,
100% CPU-Last verbrauchen, Load geht auf 10
und irgendwann bekommen manche externen Services Probleme.
Für mich sieht das so aus, als ob samba-ad-dc stalled und nichts mehr liefert.

Klar, jetzt werden massiv Projekte angelegt, es wird von der Cloud aus oft LDAP-GRuppen etc. abgefragt.

Wie kann ich das sinnvoll debuggen?

Kann ich nur den LDAP-Teil von samba debuggen?
Wo stelle ich sinnvoll welche loglevel ein?
Wenn ich Samba neu starte, habe ich erst mal Ruhe…

Ich starte mal meinen Server mit 8 statt 4 CPUs aber mehr kann ich nicht machen, ich vermute stark, dass sich das Problem nur verzögert.

VG, Tobias

ii  linuxmuster-base7              7.0.79-0ubuntu0 all          linuxmuster.net configuration scripts
ii  linuxmuster-client-servertools 0.9e            all          linuxmuster serverside scripts for managing a community based ubuntu-cloop
ii  linuxmuster-linbo-common7      2.3.66-1        all          linuxmuster-linbo common files: kernel, initrd and pxe boot configuration
ii  linuxmuster-linbo7             2.3.66-1        all          linuxmuster-linbo scripts
ii  linuxmuster-prepare            0.7.4-0ubuntu0  all          linuxmuster.net pre setup configuration scripts
ii  linuxmuster-webui7             1.0.148-1       all          next generation web-based management tool for linuxmuster.net v7.x

Tobias · 13. September 2020 um 20:50

Moment, ich kann das Problem sogar genauer reproduzieren:
In der NC habe ich seit der Umstellung auf Version 19 das Problem, dass die eine App (external sites) die LDAP Gruppen abfragt und dabei in einen Timeout gerät (60sek).

Diese Abfrage erzeugt sofort (genau einen für jeden der externen sites) samba-Prozess, der maximale Leistung fordert… Dann bin ich mit 11 samba-PRozessen, die sich 4 (oder 8) CPU-cores teilen am Anschlag.

Die NC gibt nach den 60 Sek. auf. Der Samba-Prozess rödelt weiter…

Hilft das bei der Fehlersuche?

garblixa · 15. September 2020 um 12:36

Hallo Tobias,

hast Du in der Nextcloud LDAP / AD Integration den Cache für LDAP Abfragen aktiviert?

LDAP/AD Integration - Fortgeschritten - Verbindungseinstellungen - Speichere Time-To-Live zwischen

Der Standardwert beträgt hier 600 Sekunden.

Viele Grüße
Klaus

Tobias · 16. September 2020 um 08:48

Hallo Klaus,

danke, das werde ich checken.
Traue mich grade nicht irgendetwas zu machen, weil jetzt gerade 30 Fünftklässler den Computerraum stürmen und ich live versuche den Samba + den Linuxclient dazuzubringen, ihren Job zu tun.

Vllt. hat das auch was mit meinem Samba zu tun:

anmeldeprobleme: sssd auf dem linuxclient kann sporadisch per „id username“ den User nicht finden. Die Verbindung zum AD ist offensichtlich gestört (sssdctl domain-status bei aktiviertem „ifp“ in /etc/sssd.conf liefert „OFFLINE“.)
Dann starte ich den Samba auf dem Server neu (der gerade in einem sophomorix-check festhing) und dann ist der Client wieder online.
Leider ist in so einer SItuation, wo sich der Server „erholt“ und der client sich verbindet, irgendwas am SSO gestört, so dass dann nach der Anmeldung moz-proxy kommt und man sich re-auth muss. Das ist mit 5-klässlern mit einem neuen Passwort „)Jsf8g4“ nicht zu machen.

Ich vermute, das hängt alles bei mir zusammen: der Samba reagiert schlecht oder gar nicht mehr, ein Neustart hilft zwar, aber das ganze ist fragil, irgendetwas scheint den Zustand zu triggern. Entweder super hohe Last oder ein anderes Problem.

VG, Tobias

garblixa · 16. September 2020 um 10:11

Hallo Tobias,

das Nextcloud Addon external sites mal deaktivieren, samba neu starten, bzw. beenden, hängende Prozesse killen, starten. Beobachten. Denn wenn das wirklich eine so hohe Last erzeugt, dann könnte es doch auch sein, daß die sssd Probleme daher kommen.

Viele Grüße
Klaus

Tobias · 21. September 2020 um 06:50

Hi Klaus,

danke für deine Vorschläge. Ich suche inzwischen nicht mehr nur in der Cloud. Ich habe ja massive Anmeldeprobleme und habe daher mal den Client up-to-date gemacht.
Sehe aber immer noch PRobleme. Hier mein Protokoll, was ich mache, um zu debuggen:

auf den Clients sssd-tools installieren, dann ifp als service in sssd.conf eintragen
auf dem Server samba restarten und diverse log level Einträge hochsetzen, dadurch bekomme ich in /var/log/samba/log.samba und /var/log/samba/log.smbd mehr Output.

Ich weiß leider immer noch nicht, nach was ich suchen soll, außer dass ich die sporadische Rückmeldung kriege, dass Kollegen sich nicht oder nach dem 5- Mal einloggen können. Das können nicht alles PAsswortprobleme sein, daher suche ich nach Problemen auf den Clients.

Tests:

sssctl domainstatus $(sssctl domain-list) auf den Clients ausführen
id username auf den Clients ausführen

ersterer Test liefert jetzt (mit den neuen Clients und früh am Morgen):

Online status: Online

Active servers:
AD Global Catalog: server.LINUXMUSTER.MEINESCHULE.DE
AD Domain Controller: server.LINUXMUSTER.MEINESCHULE.DE

Discovered AD Global Catalog servers:
- server.LINUXMUSTER.MEINESCHULE.DE

Discovered AD Domain Controller servers:
- server.LINUXMUSTER.MEINESCHULE.DE

zweiterer Test liefert aber unterschiedliche Ergebnisse: von 21 frisch gestarteten Clients liefern 18 alle Gruppenzugehörigkeiten zurück, z.B.

uid=1340601345(testuser) gid=1340600513(domain users) Gruppen=1340600513(domain users),1340603401(p_fachlehrer_6c_2021),1340603164(role-teacher),1340601115(all-webfilter),1340601112(webfilter),1340601122(all-internet),1340601107(internet),1340601119(all-intranet),1340601108(intranet),1340601124(all-printing),1340601109(printing),1340601103(schools),1340601104(s_default-school),1340601110(students),1340601120(all-students),1340602244(p_wifi),1340601123(all-teachers),1340601111(teachers),1340601125(all-wifi),1340601113(wifi),1340603463(p_spanisch_10be_2021),1340603462(p_franzoesisch_7b_2021),1340603465(p_11b_spanisch_2021),1340603466(p_spanisch_11b_2021),1340603461(p_englisch_basisfach_wen_k1_202122),1340602223(p_fs-englisch)

(man beachte, die Spanisch-Projekte)
aber drei Clients liefern nicht alle Projekte zurück:

uid=1340601345(testuser) gid=1340600513(domain users) Gruppen=1340600513(domain users),1340603401(p_fachlehrer_6c_2021),1340603164(role-teacher),1340601115(all-webfilter),1340601112(webfilter),1340601122(all-internet),1340601107(internet),1340601119(all-intranet),1340601108(intranet),1340601124(all-printing),1340601109(printing),1340601103(schools),1340601104(s_default-school),1340601110(students),1340601120(all-students),1340602244(p_wifi),1340601123(all-teachers),1340601111(teachers),1340601125(all-wifi),1340601113(wifi)

nach einem neustart des sssd auf diesem Client kommen auch dort alle Gruppen (!)

Hat das etwas zu sagen?

Ich habe im übrigen sichergestellt, dass vor dem Image-Erstellen mit

root@r308-pc02:~# cat /var/lib/linuxmuster-image-prep.d/sss-cache.sh
#!/bin/bash

echo "Invalidating SSS Cache:"
sssctl cache-expire -d `sssctl domain-list` -E

der Cache expired wird.

Hat jemand noch Ideen, was ich jetzt probieren kann?

VG, Tobias

Tobias · 21. September 2020 um 06:59

Auch hier kann/muss ich mir wieder selbst antworten:

Vermutlich nicht. Nach einem gewissen Zeitraum kann ich mit der Abfrage „id testuser“ oder auch einem anderen user, der noch nicht abgefragt wurde, keine Unterschiede zwischen den Clients mehr feststellen: alle 21 Clients liefern den gleichen output (allerdings gruppen in unterschiedlicher Reihenfolge aufgelistet, d.h. der output ist nicht identisch).

sssd braucht scheinbar eine Weile um sich an die Domäne zu gewöhnen. Die ersten Befehle mit abweichendem Output bei einzelnen waren ca. 30 min. nach start der Rechner…
Aber das Bild zeichnet sich etwas undurchsichtig: Evtl. sind die Rechner, die länger schon in der Domäne sind, eher betroffen als die, die zuletzt gestartet wurden.

baumhof · 21. September 2020 um 13:32

Hallo Tobias,

… das ist ja ein echtes Mistproblem …

Ich kann dir leider auch nur ganz allgemeine Gedanken zum Problem mitgeben.
Da wir alel den „gleichen“ server haben (hast du vanilla install gemacht
oder die ovas verwendet?) glaube ich nicht, dass es ein generelles
Serverproblem ist: das würde ja alle betreffen.

Beschreib nochmal den Werdegang:
zuerst hast du Loginprobleme an der nextcloud bemerkt, dann gesehen,
dass auf dem Server einzelne Dienste amok laufen (Serverlast) und hast
nach der Ursache dieser Last gesucht.
Jetzt kommen (neuerdings?) Loginprobleme auch im lokalen Netz dazu.
Siehst du auch dabei Lastspitzen auf dem Server?
Bestehen die Nextzcloudprobleme fort?

Also vergleichen wir zwei mal unser Setting:
Virtualisiert mit KVM auf LVMs als Storage
Mein Server hat 10 Cores und 12 GB RAM bekommen (Ryzen 2700)
Er versorgt ca. 300 Clients mit 1400 Nutzern.
Mein Storage ist 5x4TB SATA HD mit 7200U/min (RAID5)
Der Host läuft auf einer 120GB SSD

Ich habe gesubnettet mit einem Cisco SG350X.
Aber du hast Subnets mit einem HP, oder?

Als du letzte WOche das erstemal von der Systemlast geschrieben hast hab
ich gleich auf meinem Server nachgeschaut, ob ich das auch habe: ich
konnte nichts finden

LG

Holger

Tobias · 21. September 2020 um 20:18

Hi Holger,

danke, ich kann das Setting gerne vergleichen und mir schwant ja auch, dass ich einfach alte Hardware habe. Will nur nicht so recht an Performanzprobleme glauben

6 cores und 6 GB RAM (oller Intel)
150 Clients mit 900 Nutzern
Storage: 5x1TB SATA HDD mit ?? U/min, vermutlich auch 7200 (RAID5)
Host auf einer 250GB SSD

Subnetze mit einem HP 5400zl oder so ähnlich, schweineteuer.

Ich glaube langsam, dass meine Nextcloud und mein Ausfall/test-Nextcloud server die Schuldigen sind. Ich habe daher mal den test-server vom Netz genommen (also php dort abgeschalten, denn nginx brauche ich noch) und auch bei dem produktiv-System den Cron-Job abgeschalten.

Das Phänomen ist nämlich folgendes: sobald ich auf der Cloud manuell den php-Cronjob starte, kann es sein, dass der „hängt“. Es hängt nicht wirklich, denn er zeigt mit Fehlermeldungen /var/run/samba/msg.lock sei nicht schreibbar, dass er wirklich was zu tun hat. Leider müsste ich an der STelle nextcloud debuggen, was bislang erfolglos war… Das nicht deterministische ist nämlich, dass ich php killen kann und der nächste PHP-Cronjob-Aufruf einfach durchgeht ohne Fehlermeldung und so weiter.
Wenn ich den cronjob kille, dann geht auch die Last auf dem lmn-server runter.

Meine Vermutung ist, dass die Nextcloud irgendwo nicht mit Gruppen zurechtkommt, die es aus dem LDAP oder aus den Circles holt. Beide scheinen mir nicht wirklich super stabil zu sein. Da gibt es immer wieder bugs, vor allem bei den Circles.

Noch ein Faktor eventuell: ungeduldige User, die den autostart abbrechen und „unsynchronisiert“ starten. Hab ich heute probiert: leider wird meine sssd.conf dann nicht mit den richtigen Rechten (600) ausgeliefert und dann geht gar nix bei der Anmeldung.

Also: Eventuell ein Zusammenspiel von vielen Kleinigkeiten.

P.S: den service „ifp“ im sssd.conf neben pam und nss zu aktivieren halte ich für super sinnvoll, auch für weiteren support und debugging bei anderen. Leider ist das die einzige Funktion, die mit einem upgrade auf ubuntu 20.04 die Segel streicht. Ich könnte also schon locker auf 20.04 upgraden, wenn das „ifp“ dann noch funktionieren würde…

Danke für die Rückmeldung.

garblixa · 2. Oktober 2020 um 11:48

Hallo Tobias,

Das heißt für mich, daß Du ein Nextcloud Storage über SMB auf OS Ebene eingebunden hast?
Denn wenn man die Nextcloud App „External Storage“ verwendet, dann wird das SMB Storage im Kontext des Webserver Users www-data eingebunden.

Hast Du auch eine hohe Mysql Last(also falls die Datenbank bei Dir Mysql ist), wenn der Nextcloud Cron läuft?

Oder mit dem External Storage.

Viele Grüße
Klaus

Tobias · 7. Oktober 2020 um 08:53

Hallo zusammen,

ich habe das Problem jetzt eingedämmt.
@garblixa und @baumhof: Danke für die Hilfe.

Problem: evtl. ist smbclient an den Fehlermeldungen schuld und daran, dass die Cron-jobs die nextcloud absetzt ziemlich lange dauern. Debuggen konnte ich das noch nicht. Ich habe smb-external storages eben wieder abgeschalten (app sogar deaktiviert)
Problem: LDAP, das ist echt übel: Gruppen in Gruppen darf ich bei mir nicht aktivieren. Ihr findet die Konfiguration (noch) in der aktuellen Doku: https://docs.linuxmuster.net/de/latest/external-services/nextcloud/index.html#einstellungen-fortgeschritten und zwar „Eingebundene Gruppen“ darf ich bei mir einfach nicht aktivieren. Die Folge ist logisch: er sucht bei Gruppenzugehörigkeiten oder allgemein bei der Rückgabe von Gruppen (hier bei mir in der App: External Sites) eben nach GRuppen im LDAP und geht wohl der Vernestung nach.

Neben dem Effekt, dass ich ca. 100 Projekte inzwischen habe und auch natürlich meine ca. 40 Klassen , findet Nextcloud-LDAP-Integration so ca. 170 Gruppen bei mir. Die „External Sites“ App (und evtl. auch der Cronjob) stößt einen samba-ad-dc-Prozess auf dem Server an, der aber sehr lange mit der Rückmeldung braucht - ganz sicher wegen des Gruppen-in-Gruppen features. Sobald ich das abschalte, ist der Prozess schnell wieder zurück.

Dann kommt noch dazu, dass PHP da einen 60 Sekunden Timeout drinhat, so dass die Nextcloud nach 60 denkt, mit dem LDAP stimmt was nicht. Ich habe auch den Switch gefunden um das hochzuschrauben in meiner nginx/php Konfiguration, aber das bringt ja nichts, wenn der Server mit der Rückmeldung so lange braucht.

Dann kam dazu, dass die NExtcloud pro external sites einen LDAP-Befehl absetzt um die GRuppen zu bestimmen, bei X external sites habe ich X samba prozess mit 100% die ein paar Minuten brauchen um die GRuppen zurückzuliefern - und bäm, ist mein Server am Anschlag. Das ist nicht unbedingt Fehler des Sambaservers.

Tatsächlich habe ich das caching feature von @garblixa nicht ausprobiert. Aber das ist auch nur ein workaround, der dann die Komplexität möglicherweise noch erhöht.

Warum ich das ganze jetzt noch länger schreibe: Ich kann zwar bei mir das Problem eindämmen, aber der Fakt, dass ich es schaffe den LDAP-Server so zu beschäftigen, kann auch bei anderen mal anschlagen, das gefällt mir nicht. Vllt. stimmt etwas auf dem Server mit der gruppen-vernestung nicht, bei mir, oder bei allen?

Das zweite Problem ist bei mir, dass (vermutlich) durch die teilweise hohe Last auf dem Server, die Linuxclients nicht zuverlässig eine Anmeldung erlauben. Ich habe das Gefühl, dass die Unzuverlässigkeit der Linuxclient-domänengebundenen Anmeldung nicht nur bei mir >0 ist. Jedenfalls war das in der 6.2 mit dem „einfachen“ LDAP nicht so auffällig.

Das kann ich an andere Stelle noch reporten, aber ich kriege bei Aufrufen von „id kuechel“ auf meinen gleichzeitig laufenden Linuxclients ab und zu unterschiedliche Werte zurück, ebenso scheint sssd auf den Linuxclients nicht immer „Online“ zu sein, ebenso können sich auch manchmal KuK bei meinen Linuxclients nicht anmelden und das scheint sich aber auch zu erholen. Alles nichts handfestes, ich weiß.

VG so weit, ich markiere den Thread als „gelöst“, obwohl mir schwant, dass das noch nicht das Ende ist.

Tobias

Tobias · 7. Oktober 2020 um 08:54

Nachtrag: Ohne „Gruppen-inGruppen“ Feature, fehlen bei mir die „students“ und ich muss als Gruppe „role-students“ verwenden.

garblixa · 7. Oktober 2020 um 10:48

Hallo Tobias,

danke für die Infos!
„Eingebundene Gruppen“ in Nextcloud hatte ich ebenfalls nur gebraucht um die Schüler zu sehen. „cn=students“ beinhaltet aber nur weitere Gruppen. Mit „cn=role-student“ geht das und ich brauche auch „Eingebundene Gruppen“ nicht mehr.

Siehe:

@cweikl
Chris, bitte evtl. auch das mit den „Eingebundene Gruppen“ aus der Doku rausnehmen, wenn das auch noch andere bestätigen können, daß das nicht nötig ist.

Viele Grüße
Klaus

carsten · 14. Oktober 2022 um 09:30

Wir haben ein einer Schule die gleiche Erscheinung, daß Samba Rechenzeit verbrät und die Anmeldung meistens nicht möglich ist. Ein Neustart von Samba lindert das eine gewisse Zeit.
Ich hätte gern gewußt, wie Ihr auf die Ursache in Eurem Falle gekommen seit.
Wo sehe ich, welcher Prozeß das Samba blockiert?
Warum beruhigt sich Samba nicht wieder?
Warum reicht ein Samba, der alles blockiert? Es sind doch viele Sambaprozesse, welche zur Verfügung stehen.

michael_kohls · 14. Oktober 2022 um 15:15

Hallo Carsten!
Eine solche Erscheinung hatte ich auch vor geraumer Zeit. Bei mir ist dann pro Tag ein weiterer Samba-Prozess dazugekommen, der mit nahezu 100% läuft. Ab 5/6 Prozessen hat sich das dann auch beim Zugriff bemerkbar gemacht. Wenn bei dir schon 1 Prozess reicht, dann ist dein Plattensystem damit halt ausgelastet.
Die Ursache war die Nextcloud nach einem bestimmten Update. Hatte dann erst mal auf die vorherige (22.2.10) zurückgesetzt. Dann war es wieder okay. Aber irgendwann muss ich der Sache mal auf den Grund gehen.
VG
Micha

carsten · 16. Oktober 2022 um 14:50

Hallo Micha,

wie sehe ich, wer das Samba quält?
Wie konntest Du als Ursache die Nextcloud zuordnen?

michael_kohls · 17. Oktober 2022 um 09:39

Hallo Carsten,
schau mal mit iftop, ob von der Nextcloud übermäßig starker Netzwerkverkehr kommt. Das ist zumindest ein Hinweis. Ein Neustart der Nextcloud behebt das Problem für kurze Zeit.
Viele Grüße
Micha