12
Synology: smbd main process (10144) killed by TERM signal
Moin,
wir haben ein etwas seltsames Problem mit einem Synology DS718+. Das Teil ist in die Domain eingebunden und funktioniert eigentlich so, wie es soll. Nur in einem Abstand von ca. 14 Tagen (manchmal aber auch schon nach zwei) rufen die User an und melden, dass kein Zugriff mehr möglich ist. Vor meinem Urlaub habe ich mir das Teil angeschaut und festgestellt, dass er sich die Zeit nicht beim richtigen Zeitserver holt und deshalb die Uhren auseinandergelaufen sind (NTP auf externe Quellen blockt unsere FW). Da dachte ich, dass das das Problem sei. Heute beschwerten sich die User wieder. Im Web-Interface schien alles in Ordnung zu sein. Trotzdem kein Zugriff. Also habe ich mich per ssh eingeloggt und mir die Logs angeschaut. In /var/log/messages steht:
Das passt auch zu den Ausfallzeiten. Wer oder was killed da immer den smbd? Kennt das jemand? Google gibt mir leider bei der Suche nur fünf Treffer, die mit dem Phänomen nicht wirklich was zu tun haben.
Liebe Grüße
Erik
wir haben ein etwas seltsames Problem mit einem Synology DS718+. Das Teil ist in die Domain eingebunden und funktioniert eigentlich so, wie es soll. Nur in einem Abstand von ca. 14 Tagen (manchmal aber auch schon nach zwei) rufen die User an und melden, dass kein Zugriff mehr möglich ist. Vor meinem Urlaub habe ich mir das Teil angeschaut und festgestellt, dass er sich die Zeit nicht beim richtigen Zeitserver holt und deshalb die Uhren auseinandergelaufen sind (NTP auf externe Quellen blockt unsere FW). Da dachte ich, dass das das Problem sei. Heute beschwerten sich die User wieder. Im Web-Interface schien alles in Ordnung zu sein. Trotzdem kein Zugriff. Also habe ich mich per ssh eingeloggt und mir die Logs angeschaut. In /var/log/messages steht:
2019-06-05T06:30:23-07:00 server [ 1164.121092] init: smbd main process (9681) killed by TERM signal
2019-06-05T15:39:06+02:00 server [ 1724.901421] init: smbd main process (15655) killed by TERM signal
2019-06-13T09:27:30+02:00 server [670599.796019] init: smbd main process (22472) killed by TERM signal
2019-06-13T09:30:29+02:00 server [ 154.189820] init: smbd main process (10144) killed by TERM signal
2019-06-13T09:34:25+02:00 server [ 389.792055] init: smbd main process (13691) killed by TERM signal
2019-06-13T09:34:37+02:00 server [ 402.193416] init: smbd main process (14817) killed by TERM signal
2019-06-13T09:44:21+02:00 server [ 985.960955] init: smbd main process (14985) killed by TERM signal
2019-06-13T09:44:42+02:00 server [ 1007.376353] init: smbd main process (18191) killed by TERM signal
2019-06-13T10:52:16+02:00 server [ 5061.885833] init: smbd main process (18380) killed by TERM signal
2019-06-13T10:52:34+02:00 server [ 5079.250333] init: smbd main process (23382) killed by TERM signal
2019-06-13T10:57:34+02:00 server [ 5381.431879] init: smbd main process (23525) killed by TERM signal
2019-06-20T09:50:13+02:00 server [600764.334964] init: smbd main process (10157) killed by TERM signal
2019-07-03T10:18:45+02:00 server [1124915.693978] init: smbd main process (10150) killed by TERM signal
2019-07-16T13:33:51+02:00 server [2259851.749014] init: smbd main process (15342) killed by TERM signal
2019-07-18T10:31:37+02:00 server [161850.144619] init: smbd main process (10501) killed by TERM signal
2019-07-25T09:28:15+02:00 server [601003.883355] init: smbd main process (10451) killed by TERM signalDas passt auch zu den Ausfallzeiten. Wer oder was killed da immer den smbd? Kennt das jemand? Google gibt mir leider bei der Suche nur fünf Treffer, die mit dem Phänomen nicht wirklich was zu tun haben.
Liebe Grüße
Erik
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 477507
Url: https://administrator.de/forum/synology-smbd-main-process-10144-killed-by-term-signal-477507.html
Ausgedruckt am: 26.03.2025 um 11:03 Uhr
12 Kommentare
Neuester Kommentar
Moin,
Firmware ist aktuell?
Kannst du mal schauen ob du in den Logs von smbd mehr Informationen findest?
mfg
Firmware ist aktuell?
Kannst du mal schauen ob du in den Logs von smbd mehr Informationen findest?
mfg
Moin,
Jein. Heute kam ein neues Update. Das wird gerade installiert. Insofern war die Kiste bis heute auf dem aktuellen Stand.
Hab ich schon. Leider nein.
Liebe Grüße
Erik
Jein. Heute kam ein neues Update. Das wird gerade installiert. Insofern war die Kiste bis heute auf dem aktuellen Stand.
Kannst du mal schauen ob du in den Logs von smbd mehr Informationen findest?
Hab ich schon. Leider nein.
Liebe Grüße
Erik
Zusätzlich RAM nachgerüstet?
Wenn ja, Speichertest gemacht?
VG
Wenn ja, Speichertest gemacht?
VG
Moin,
Nein, kein zusätzlicher Speicher und das Teil ist gerade mal einen guten Monat alt.
Liebe Grüße
Erik
Nein, kein zusätzlicher Speicher und das Teil ist gerade mal einen guten Monat alt.
Liebe Grüße
Erik
Ggf. trotzdem mal ein Speichertest machen, nur um das auszuschließen.
Wird die Synology als reines Datengrab genutzt oder laufen da noch andere Dienste? z.B. LDAP?
VG
Wird die Synology als reines Datengrab genutzt oder laufen da noch andere Dienste? z.B. LDAP?
VG
Ich würde jetzt auch einfach mal auf den RAM tippen.
Was sagt denn der syslog?
Was sagt denn der syslog?
Speichertest läuft.
Ja, reines Datengrab. Der ist für unsere Marketingabteilung, weil die immer den normalen Fileserver vollgemüllt haben.
Ja, reines Datengrab. Der ist für unsere Marketingabteilung, weil die immer den normalen Fileserver vollgemüllt haben.
So, Speichertest ist durch. Keine Fehler. Das hätte mich auch gewundert, da Samba ja ein SIGTERM bekommt und sauber runterfährt. Kaputter Speicher führt ja eher zu unkontrollierten Abstürzen ohne Logeinträge.
Außerdem habe ich mir die Cronjobs angeguckt. (Warum ist da kein normales Linux drauf, bei dem man nicht jeden Befehl nachschlagen muss? ) Da ist auch nichts, was das auslösen könnte. Aber irgend etwas muss ja SIGTERM an den Sambaprozess schicken. Nur welche Software macht das. Oder wollen mich die Kollegen ärgern?
Nun ist endlich Feierabend. Bis morgen.
Außerdem habe ich mir die Cronjobs angeguckt. (Warum ist da kein normales Linux drauf, bei dem man nicht jeden Befehl nachschlagen muss?
) Da ist auch nichts, was das auslösen könnte. Aber irgend etwas muss ja SIGTERM an den Sambaprozess schicken. Nur welche Software macht das. Oder wollen mich die Kollegen ärgern? Nun ist endlich Feierabend. Bis morgen.
Im netz schwirren ein paar Fehler mit dem smbd rum die mit Speichern zu tun hatten und bei denen es auch einen SIGTERM für den smbd gab.
Aber wenn der Speicher i.O. ist weiter im Text.
Was steht im Samba log?
Aber wenn der Speicher i.O. ist weiter im Text.
Was steht im Samba log?
Nur dass Ihr nicht denkt, dass ich Euch die Lösung nicht verraten will. Wir haben einen Totalausfall der TK-Anlage. Wahrscheinlich geht's mit dem Problem erst Montag weiter.
Wir haben einen Totalausfall der TK-Anlage. Wahrscheinlich geht's mit dem Problem erst Montag weiter.
ggf. auch mal das log level vom samba hochsetzen..
So, TK-Anlage läuft wieder. 
Loglevel des Samba habe ich auf 3 gesetzt. Die Logs sagen nicht wirklich was Brauchbares aus. Das einzige sind die SIGTERMs, die, wie ich mittlerweile festgestellt habe, nicht nur Samba, sondern auch andere Prozesse bekommen. Woher auch immer. Jetzt warte ich mal, bis das wieder auftritt in der Hoffnung, dass mit den erhöhten Loglevels was drin steht, was zum Fehler führt. Ich werde berichten.
Liebe Grüße und schönes Wochenende
Erik
Loglevel des Samba habe ich auf 3 gesetzt. Die Logs sagen nicht wirklich was Brauchbares aus. Das einzige sind die SIGTERMs, die, wie ich mittlerweile festgestellt habe, nicht nur Samba, sondern auch andere Prozesse bekommen. Woher auch immer. Jetzt warte ich mal, bis das wieder auftritt in der Hoffnung, dass mit den erhöhten Loglevels was drin steht, was zum Fehler führt. Ich werde berichten.
Liebe Grüße und schönes Wochenende
Erik
