Prozesse bleiben willkürlich stecken/hängen

[Dalai]

Hallo ihr .

Seit einigen Monaten haben wir ein sehr seltsames und ungewöhnliches Problem auf mehreren Systemen mit komplett unterschiedlicher Hardware und unterschiedlichen Kernel-Versionen. Ressourcen sind in Bezug auf Speicher und CPU ausreichend verfügbar. Ich halte es für sehr wahrscheinlich, dass ein Zusammenhang mit dem vor wenigen Monaten durchgeführten Upgrade auf Ubuntu 18.04 besteht, denn vorher gab es solche Probleme über viele Jahre hinweg nicht. Aber wo genau der Zusammenhang liegt, ist völlig unklar.

Das Problem
Prozesse bleiben zu unterschiedlichen Zeiten einfach stehen, tun nichts mehr, und haben laut top/htop den Status S, also sleeping. Sie verursachen keine CPU-Last, der Speicherverbrauch bleibt konstant. Es macht den Eindruck, als warteten die Prozesse auf irgendwas. Alle betroffenen Prozesse werden per cron gestartet. Betroffen waren bisher rsync (per rsync-Daemon aber auch per SSH) wie auch convert (von ImageMagick). Ob auch von (anderen) Serverdiensten/Daemons gestartete Prozesse betroffen sind, ist unbekannt. Töten lassen sich die Prozesse, aber das ist natürlich nicht der Sinn .

Gerade der Fall mit dem convert war sehr kurios. Der Konvertierungsprozess wird folgendermaßen ausgeführt

timeout 600 convert -density 300 -depth ...

Nun kommt die Kuriosität: Die Konvertierung brauchte ihre Zeit und bei Erreichen der 600 Sekunden versuchte das timeout wohl, den convert-Prozess zu töten (CPU-Last ging nachvollziehbar runter), der Prozess lief aber weiter und belegte weiterhin Speicher! Hätte ich das nicht durch Zufall eine Stunde später gesehen, liefe der Prozess wohl heute noch.

Heute nachmittag hab ich mich mit strace an einem der hängenen Vorgänge (rsync -v -rsh='ssh -v') versucht, aber der diesbzgl. unerfahrene Nutzer vor der Tastatur hat damit so seine Probleme

root@server:/# strace -ff -p 6937
strace: Process 6937 attached
restart_syscall(<... resuming interrupted restart_syscall ...>^Cstrace: Process 6937 detached
 <detached ...>

root@server:/# strace -ff -p 6938
strace: Process 6938 attached
select(7, [3 4], [], NULL, NULL^Cstrace: Process 6938 detached
 <detached ...>

root@server:/# strace -ff -p 6939
strace: Process 6939 attached
read(4, ^Cstrace: Process 6939 detached
 <detached ...>

Mehr Ausgaben gab's nicht. Inhalt der Datei /proc/6939/stack:

[<0>] unix_stream_read_generic+0x5e5/0x900
[<0>] unix_stream_recvmsg+0x51/0x70
[<0>] sock_recvmsg+0x43/0x50
[<0>] sock_read_iter+0x90/0xe0
[<0>] new_sync_read+0xe4/0x130
[<0>] __vfs_read+0x29/0x40
[<0>] vfs_read+0x8e/0x130
[<0>] SyS_read+0x5c/0xe0
[<0>] do_syscall_64+0x73/0x130
[<0>] entry_SYSCALL_64_after_hwframe+0x3d/0xa2
[<0>] 0xffffffffffffffff

Die Ausgaben der Prozesse (verbose) zeigen nichts Ungewöhnliches, ebenso wenig wie das Syslog. Wie bzw. wo und womit kann ich noch ansetzen, um herauszufinden, wo es klemmt? Aktuell lasse ich die o.g. Prozesse (PID 6937-6939) noch laufen, für den Fall, dass jemand eine Idee hat, was man tun kann.

Grüße
Dalai

 

[tspoon]

haste syslog laufen?
was sagt den ein:

grep kernel /var/loig/syslog

kann es sein das das timeout nur den hauptprozess killt aber nicht die unterprozesse?
rsync sollte 3 rsync-prozesse starten und beim ps aux auftauchen.

 

[Dalai]

Nur falls das aus dem OP nicht klar geworden sein sollte: Das Problem tritt nur hin und wieder mal auf, dem Anschein nach völlig zufällig. Bisher war es ein Fall von 25 Vorgängen mit convert und mindestens ein halbes Dutzend Fälle mit rsync (von Dutzenden).

haste syslog laufen?

Ja, aber wie ich schon im letzten Abschnitt des OP schrieb, ist dort nichts Hilfreiches enthalten.

kann es sein das das timeout nur den hauptprozess killt aber nicht die unterprozesse?

Das spielt für das convert keine Rolle. Der Prozess hätte getötet werden sollen, stattdessen verschwand aber nur die durch den Prozess verursachte Last, und das diesen Vorgang anstoßende Skript ging nicht weiter zum nächsten Befehl. Nach dem manuellen Töten mit kill <pid> ging's dann sofort weiter.

rsync sollte 3 rsync-prozesse starten und beim ps aux auftauchen.

Ja klar tauchen die auf, bzw. in obigem Fall sind's nur zwei, weil rsync dabei über SSH geht.

Fakt ist, dass rsync mitten in der Synchronisierung stehenbleibt, entweder nach/während dem Empfang der Dateiliste oder nach dem Übertragen einiger Dateien. Das ist in den Logs erkennbar (rsync --log-file). Hier mal noch ein Auszug aus eben diesem Log der o.g. immer noch laufenden Prozesse:

[...]
debug1: Authentication succeeded (publickey).
Authenticated to 192.168.15.254 ([192.168.15.254]:<port_redacted>).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
debug1: pledge: network
debug1: Sending environment.
debug1: Sending env LANG = de_DE.UTF-8
debug1: Sending command: rsync --server --sender -vlogDtpre.iLsf . /data/
2021/12/14 06:04:01 [6937] receiving file list
receiving incremental file list

Danach folgen nur noch weitere debug1-Zeilen vom SSH, offenbar von einem Rekey alle 8 Stunden (das Log hatte heute nachmittag einen Zeitstempel von 14:04 und aktuell 22:04).

Grüße
Dalai

 

[tspoon]

wenn ein kill geht dann versuch mal -k das sendet ein kill

timeout -k 600  convert ...

convert und rsync reagieren sehr nervös auf speicherfehler, daher die frage nach dem syslog.

rsync mag auch keine großen ordner mit tausenden oder millionen dateien, da steht das einfach irgendwann.
wenn es über shsh/netzwerk geht hilft eventuell --bwlimit die bandbreite zu limitieren. sonst ballert das mit vollspeed die daten rüber, was dann dazu führen kann das auf der anderen seite, die ssh-verbindung gedroppt wird und/oder die firewall was blockt.

bei convert kann es sein, das die parameter die übergeben werden , manchmal probleme machen bei bestimmten dateiformaten.
das fährt sich dann einfach fest. da hilft nur anpassen der parameter.

aber ohne zugriff auf das system sind das nur die ersten dinge, die ich so im gedächtnis habe zu beiden programmen.

 

[Dalai]

wenn ein kill geht dann versuch mal -k das sendet ein kill

timeout -k 600  convert ...

Das kann ich probieren, aber ich habe aus zwei Gründen starke Zweifel, dass es etwas hilft

• Es lief über viele Jahre völlig problemlos mit derselben Kommandozeile für Tausende konvertierte Dateien
• Auf den beiden betroffenen Systemen beendet rsync seine Vorgänge hin und wieder auch nicht sauber, und hierbei wird keinerlei timeout verwendet.

convert und rsync reagieren sehr nervös auf speicherfehler, daher die frage nach dem syslog.

Das kann ich nicht beurteilen, aber ich bin mir ziemlich sicher, dass keine Speicherfehler vorliegen. Eines der Systeme verwendet DDR4 Registered ECC, und syslog müsste bei Auftreten von Speicherfehlern etwas protokollieren, aber wie ich schon sagte gibt das syslog/kern.log nichts in Bezug auf die problematischen Prozesse, auftretende Systemprobleme o.ä. her. Zudem betrifft es zwei Systeme, von daher halte ich es für ausgeschlossen, dass beide Systeme jahrelang die Aufgaben erledigt haben, und nun auf einmal Speicherfehler verantwortlich sein sollen.

rsync mag auch keine großen ordner mit tausenden oder millionen dateien, da steht das einfach irgendwann.

Seit mehr als 10 Jahren werden die Daten täglich zwischen den beiden betroffenen Systemen mit rsync übertragen. Die Daten umfassen mittlerweile 400 GB mit inzwischen ca. einer Million Dateien, und darunter sind einige Verzeichnisse mit Hunderten oder gar Tausenden Unterverzeichnissen und/oder Dateien. Bis vor einigen Monaten lief das ohne solches Hängenbleiben.

Seit 2014 macht ein weiteres System zweimal pro Woche mit rsnapshot Schnappschüsse von diesen Daten, ebenfalls ohne Hänger. Angesichts der vorliegenden Problematik lasse ich die Finger davon, das dritte System ebenfalls auf Ubuntu 18.04 zu aktualisieren, aber das nur nebenbei.

Insofern kann ich deine Aussage in keiner Weise nachvollziehen.

sonst ballert das mit vollspeed die daten rüber, was dann dazu führen kann das auf der anderen seite, die ssh-verbindung gedroppt wird und/oder die firewall was blockt.

Nein, der Witz ist ja gerade, dass bei den o.g. Prozessen (6937-6939), die aktuell immer noch laufen, immer noch eine SSH-Verbindung steht! Abgebrochen wird da nichts, und selbst wenn das so wäre, müsste mindestens eines der Systeme etwas darüber melden. Das ist aber nicht der Fall.

aber ohne zugriff auf das system sind das nur die ersten dinge, die ich so im gedächtnis habe zu beiden programmen.

Naja, ich habe schon Zugriff . Aber ich nehme mal an, das ist nicht das, was du meintest. Wer Ideen hat, was ich mit den noch laufenden Prozessen noch testen kann, immer her damit.

Grüße
Dalai

 

[WindHund]

@Dalia
Hallo, ich kenne mich mit den Programmen nicht persönlich aus, auch nicht mit Linux.
Aber kann es an der IP Adresse Liegen ?

Nachdem das Betriebssystem erfolgreich installiert wurde werden wir unseren Homeserver nun für den Fernzugriff vorbereiten. Dazu vergeben wir als erstes eine Feste IP Adresse um sicherzustellen dass der Server immer unter der gleichen Adresse erreichbar ist.
Die Adresse wird in der Datei /etc/network/interfaces angegeben.

feste IP Adresse vergeben und Login per SSH - techgrube.de

Nachdem das Betriebssystem erfolgreich installiert wurde werden wir unseren Homeserver nun für den Fernzugriff vorbereiten. Dazu vergeben wir als erstes eine Feste IP Adresse um sicherzustellen dass der Server immer unter der gleichen Adresse erreichbar ist. Die Adresse wird in der Datei...

www.techgrube.de

Falls es das nicht ist, welches Datei-System nutzt du und bist du sicher das es keine Restriktionen gibt bezüglich der Anzahl?
Immerhin ist dein Sync immer größer geworden mit der Zeit.
Bei Windows gibt es öfter mal falsche größen Angaben von Dateien, auch ohne Speicher Fehler (FAT).
Daher evt. mal die Platten auf Fehler prüfen lassen (Windows: chkdsk c: /f)

 

[Dalai]

Alle beteiligten Systeme sind Server, und als solche bekommen die natürlich eine feste IP-Adresse - das war auch schon immer der Fall.

Die Dateisysteme sind alle ext4 (und einmal ext3). Alle Dateisysteme haben die unter Linux übliche (oder inzwischen nicht mehr übliche) Intervallprüfung aktiviert, so dass nach einer bestimmten Zeit bzw. einer Anzahl von Mountvorgängen eine Prüfung vorgeschlagen wird. Diese Prüfung wird dann üblicherweise in den folgenden Wochen/Monaten auch durchgeführt. Insofern können auch Dateisystemfehler (nahezu) ausgeschlossen werden. Sollten welche auftreten, werden diese im Syslog protokolliert.

---

Vor Weihnachten hab ich ein paar Änderungen gemacht:

• Die Synchronisierung der Daten erfolgt nun in allen Fällen mit dem rsync-Schalter --numerid-ids, damit die Owner unverändert übernommen werden (und kein Mapping von uid zu id erfolgt)
• Der LDAP-Client hat für bestimmte Vorgänge Timeouts bekommen, einmal fürs Herstellen der Verbindung und zum anderen fürs Suchen in der DB. Aus irgendeinem Grund gibt es standardmäßig für keinen dieser Vorgänge ein Timeout.
• Ein paar Dutzend Dateien hatten keinen Owner mehr zugeordnet sondern nur noch eine uid, weil mit der Zeit einige Nutzer aus dem LDAP gelöscht wurden; diese Dateien haben nun wieder einen sauberen Owner.

Meine Hoffnung ist, dass mindestens eine dieser Änderungen das Problem behebt. Aufgrund der Zufälligkeit des Auftretens des Problems (und der ggf. langen Zeit, bis es passiert) werden wir abwarten müssen, ob es nun behoben ist. Selbst wenn das der Fall sein sollte, stellt sich die Frage, warum es vorher über viele Jahre funktioniert hat...

Grüße
Dalai

 

[Riddler82]

Willkürlich bleibt eigentlich selten was stehen, es gibt immer einen Grund.
Nur wenn es keine Logeinträge gibt und strace nicht ausgibt, kann man nicht wirklich analysieren, klar.

Wir arbeiten viel mit rsync, aber das von dir beschriebene Verhalten hatten wir bisher auch noch nie, so weit ich weiß.

Was mir nicht ganz klar ist, habt ihr auf den Quellservern auch geschaut ob da dann jeweils alles in Ordnung ist?

 

[Berniyh]

Würde den rsync mal auf einen Teilbereich beschränken und schauen ob es dann immer noch passiert.
evtl. ist es ja ein ganz bestimmter Teil der Daten der das Problem verursacht?

 

[Dalai]

Willkürlich bleibt eigentlich selten was stehen, es gibt immer einen Grund.

Da hast du recht. Gemeint war willkürlich im Sinne von "nicht nach einem System erfolgend" oder "zufällig".

Wir arbeiten viel mit rsync, aber das von dir beschriebene Verhalten hatten wir bisher auch noch nie, so weit ich weiß.

Wenn ich Bock hätte, könnte ich jetzt eine Statistik errechnen, wieviele Dateien und Datenmengen über die vielen Jahre problemlos per rsync übertragen wurden. Aber es langt wohl, wenn ich sage, dass in dem einen Fall die Daten täglich synchronsiert werden (die weiter oben erwähnten 400 GB), im anderen Fall dreimal pro Woche (weniger als 2 GB). Insgesamt also sehr viele Terabyte an übertragenen Daten. Erst seit einigen Monaten gibt's die Probleme.

Was mir nicht ganz klar ist, habt ihr auf den Quellservern auch geschaut ob da dann jeweils alles in Ordnung ist?

Eigentlich dachte ich, das wäre aus dem Kontext des Problems hervorgegangen. Aber wenn du schon fragst: Ja, es ist alles in Ordnung. Mal zur Verdeutlichung die beteiligten Systeme und die Richtung der Datenflüsse:

Server A -> Server B per rsync-Daemon
Gateway -> Server A per rsync über SSH

Server A und B sind die im Threadverlauf erwähnten betroffenen Systeme, der Gateway ist in dem Fall nur die Datenquelle.

Würde den rsync mal auf einen Teilbereich beschränken und schauen ob es dann immer noch passiert.

Das ist vielleicht theoretisch zielführend, aber praktisch keine Option. Produktivdaten müssen zwischen den Systemen synchronisiert sein, da kann man nicht einfach eine Teilmenge der Daten auf unbestimmte Zeit unsynchronisiert lassen.

evtl. ist es ja ein ganz bestimmter Teil der Daten der das Problem verursacht?

Nein. Kein System loggt Ungewöhnliches während der Vorgänge, weder in Bezug auf Netzwerk noch auf Datenträger. Aber bitte hängt nicht alles am rsync auf. Das convert ist ebenfalls betroffen, und dabei könnte nur das lokale Dateisystem bzw. die Datenträger das Problem sein - ist aber nicht der Fall, wie ich schon mehrfach sagte.

Grüße
Dalai

 

[Riddler82]

Eigentlich dachte ich, das wäre aus dem Kontext des Problems hervorgegangen. Aber wenn du schon fragst: Ja, es ist alles in Ordnung.

Wenn du wüsstest wie oft ich das schon gehört habe "Bei uns ist alles in Ordnung, das muss an euch/euren Systemen liegen!" und dann war halt nix in Ordnung, was dann erst nach gezielter Nachfrage rauskam.
Bei ein paar hundert Servern die wir betreuen kommt über die Jahre einiges zusammen, was skurile Fehler angeht.
Grade auch bei ImageMagick oder PHP-Updates. Bei einem Kunden ging ein Script nicht mehr, bei einem der letzten PHP-Updates, weil er unwissentlich eine Sicherheitslücke darin ausgenutzt hatte, die nach Jahren entdeckt und geschlossen wurde.

Mir fällt zu deinem konkreten Fall aber echt auch nicht viel mehr ein, als du/ihr schon gemacht hast.
Zum Vorschlag von Berniyh, man könnte die rsync-Aufträge in mehrere Separate aufsplitten die dann nacheinander abgeabeitet werden.

Wir arbeiten fast nur mit CentOS/RHEL, von daher ist meine Erfahrung natürlich nur bedingt übertragbar...

 

[Berniyh]

Mir fällt zu deinem konkreten Fall aber echt auch nicht viel mehr ein, als du/ihr schon gemacht hast.
Zum Vorschlag von Berniyh, man könnte die rsync-Aufträge in mehrere Separate aufsplitten die dann nacheinander abgeabeitet werden.

Das, oder man richtet ein Zweitsystem zum Testen ein auf das auch übertragen wird.
Oder auf dem Zielsystem eine weitere Datenpartition für ein zweites, separates Backup mit dem man experimentieren kann.

 

[Dalai]

Seit meiner Änderung vor Weihnachten ist das Problem auf keinem der Systeme wieder aufgetreten. Zwar wurde das convert nicht allzu häufig tätig (weil es nur hin und wieder was zu konvertieren gab), aber die Synchronisierung per rsync lief auf dem einen System täglich, auf dem anderen 3x pro Woche.

Bei genauerer Überlegung kommt man zum Schluss, dass ein fehlendes Timeout durchaus zu dem beschriebenen Fehlerbild passt. Insofern ist es plausibel. Andererseits passt das nicht so ganz in mein "Weltbild", dass es in älteren Ubuntu-Versionen funktioniert hat. Aber vielleicht gab es im Code ein festgelegtes Timeout, obwohl die Dokumentation/Manpage in allen Fällen/Versionen sagt, es gibt per default keines. Vielleicht war das ein Bug (im Code) und der wurde behoben. So tief graben will ich aber nicht.

Anyway, ich betrachte das Problem vorerst als gelöst. Sollten sich dennoch - wider Erwarten - Neuigkeiten ergeben oder das Problem zurückkehren, werde ich mich hier wieder melden.

Grüße
Dalai