white-rabbit2
Goto Top

Samba: task(ldap) pre-forked worker - 100 Prozent CPU Last

Hallo.
Wir haben vor laaaanger Zeit einen Linux-Server mit Samba und AD eingerichtet.
Nun ist es so, dass auf dem Server der Prozess
 samba: task[ldap] pre-forked worker(3)
immer wieder 100% CPU Last erzeugt:
ae3d282bc78427a88ac36856d0a48a37a5de6be6

Zwar sind Anmeldungen via Auth: [LDAP,simple bind/TLS] (z.B. über eine Webseite) weiterhin problemlos möglich, doch wenn es ein User an einem lokalen Client versucht, klappt die Anmeldung häufig nicht (wenn es zu viele User auf einmal versuchen). Wenn ich den Dienst
service samba-ad-dc restart  

neu starte, ist die CPU-Last kurz unten aber nach kurzer Zeit fährt sie dann wieder hoch.

Natürlich habe ich schon das Log-Level höher gedreht:
# Debug-Mode:
log level = 3 passdb:5 auth:5 auth_audit:3
max log size = 10000

In der Logdatei "log.samba" sehe ich sehr häufig Meldungen wie diese hier:
[2023/09/28 08:20:24.071732,  2]
 ../../auth/auth_log.c:647(log_authentication_event_human_readable)
 Auth: [Kerberos KDC,ENC-TS Pre-authentication] 
user [(null)]\[RAUM2-PC30$@LINUX.MEINE-SCHULE.DE] at 
[Thu, 28 Sep 2023 08:20:24.071711 CEST] with [aes256-cts-hmac-sha1-96] status 

[NT_STATUS_WRONG_PASSWORD]

 workstation [(null)] 
remote host [ipv4:10.20.200.30:42963] mapped to [LINUX]\[RAUM2-PC30$]. 
local host [NULL] 

Die Meldung mit dem falschen Passwort kann allerdings nicht stimmen, da es kurze Zeit später auch so aussehen kann:
Auth: [Kerberos KDC,ENC-TS Pre-authentication] ... [NT_STATUS_OK]. 
In dem Fall hat die Anmeldung natürlich geklappt. Leider ist der Fehlerfall nicht leicht zu reproduzieren: Der o.g. genannte Prozess läuft zwar auf 100% CPU-Last aber wenn man sich alleine anmeldet, klappt es trotzdem noch. Erst wenn es viele User (z.B. eine ganze Schulklasse) gleichzeitig versuchen, klappt die Anmeldung bei vielen Benutzern nicht und liefert dann auch die o.g. Meldung. Wenn man etwas wartet und es "nach und nach" versucht, gelingt die Anmeldung wieder (so dass es nicht an einem falsch eingegebenen Passwort liegt!).
Die Frage ist natürlich: Wie kann man das genauer untersuchen? Welche Prozesse treiben den samba-Task so in die Höhe, dass kaum noch was anderes geht?
Hat jemand eine gute Idee? Danke!

Content-Key: 8170844313

Url: https://administrator.de/contentid/8170844313

Printed on: December 3, 2023 at 15:12 o'clock

Member: commodity
commodity Sep 28, 2023 at 21:05:17 (UTC)
Goto Top
Es überrascht mich immer wieder, dass selbst langjährige Mitglieder (selbst) aus der Nutzergruppe der Administratoren hier nicht in der Lage sind, eine Frage einigermaßen angemessen zu stellen. Dabei gibt es sogar eine FAQ dafür: Wie Du eine Frage richtig stellst

Minimum wären doch bitte das verwendete Linux, dessen Version, die Samba-Version, die zugrunde liegende Hardware, Blech oder virtuell und eventuelle Spezialitäten aus der Konfiguration. Weitere Dienste? Auch, wie viele User dran hängen und wieviele GPOs wäre sicher interessant. Hilfreich wäre es sicher auch, einen Netzwerktrace zu machen, um zu klären, ob und ggf. wie die Last vom Netzwerk reingetragen wird.

Mit den entsprechenden Infos können dann vielleicht die wenigen Linux-Samba-Spezialisten hier (zu denen ich leider nicht gehöre) etwas anfangen.

Ohne Weiteres:

Wenn die Möhre so alt ist, ist sie vielleicht etwas zu schwach für den Usecase? Vielleicht sind die Anforderungen gestiegen? Läuft u.U. noch was auf der Kiste, was Ressourcen nimmt? Etwa gar Samba-FS? Oder gar eine Nextcloud?
Wie bei den Kollegen hier? (Irgendwie klingt Dein Usecase ähnlich face-wink )
https://ask.linuxmuster.net/t/v7-samba-prozesse-gehen-durch-die-decke/61 ...

Generell gilt, auch für Informatiklehrer, ein DC ist ein DC, ist ein DC. Nichts sonst. Und auch der muss mal erneuert werden face-big-smile

Viele Grüße, commodity