Mein NAS steht seit zwei Tagen mit beiden Prozessoren unter 100% CPU-Last. Ich habe festgestellt, daß auf dem System permanent zwischen 250 und 350 "synoscgi"-Prozesse laufen. Ein Login übers Webinterface ist nicht mehr möglich. Dabei hat ein "synoscgi"-Prozess über 250 "synoscgi"-Kindprozesse, dazu kommen noch zwischen 30 und 30 Prozesse "/usr/syno/synoman/webapi/query.cgi". Woher kommen die Prozesse, was tun sie, und vor allem: wie werde ich sie los?
DS218j DSM6. - ausufernde "synoscgi"-Prozesse
- Ersteller mksmr
- Erstellt am
Hallo mksmr,
Bücher und Hardware zum Thema gibt es bei Amazon: DS218j DSM6. - ausufernde "synoscgi"-Prozesse
Bücher und Hardware zum Thema gibt es bei Amazon: DS218j DSM6. - ausufernde "synoscgi"-Prozesse
Das NAS schonmal neu gestartet?
Gibt bestimmt einen Shutdown/Restart-Befehl, oder einfach paar Sekunden den Power-Schalter drücken, bis es blinkt.
Irgendwas scheint deine GUI (DSM) auszulasten.
Wenn du im Internet nach "synoscgi" suchst, dann heißt es oft "stoppe nacheinander alle Pakete und schau bei welchem die Last sinkt"
OK, da du ins DSM nicht rein kommst, dann hier also per Console
was ist da : synopkg list bzw. synopkg list | awk '{print $1}'
und dann stoppen synopkg stop <package> oder sudo synopkgctl stop <package>
Gibt bestimmt einen Shutdown/Restart-Befehl, oder einfach paar Sekunden den Power-Schalter drücken, bis es blinkt.
Irgendwas scheint deine GUI (DSM) auszulasten.
Wenn du im Internet nach "synoscgi" suchst, dann heißt es oft "stoppe nacheinander alle Pakete und schau bei welchem die Last sinkt"
OK, da du ins DSM nicht rein kommst, dann hier also per Console
was ist da : synopkg list bzw. synopkg list | awk '{print $1}'
und dann stoppen synopkg stop <package> oder sudo synopkgctl stop <package>
Reboot löst das Problem nicht, es geht unmittelbar weiter.
Die Pakete habe ich identifiziert und manuell gestoppt. Das machte ein wenig RAM frei, aber auf die Anzahl der "synoscgi"-Prozesse scheint das keinen Einfluss zu haben. Die schwanken weiterhin zwischen 250 und 350. Systemload liegt bei ca. 50.
Die Pakete habe ich identifiziert und manuell gestoppt. Das machte ein wenig RAM frei, aber auf die Anzahl der "synoscgi"-Prozesse scheint das keinen Einfluss zu haben. Die schwanken weiterhin zwischen 250 und 350. Systemload liegt bei ca. 50.
Mmh, stammt dein Screenshot von kurz nach dem Reboot oder waren da auch schon irgendwelche DSM-Anmeldeversuche im Spiel?
Hast du in letzter Zeit noch etwas geändert (DSM-Update, neue Pakete, viele neue Mediendateien, ...) oder kam das aus heiterem Himmel?
Der Process synoscgi scheint bei allen Indizierungsvorgängen tief mit drin zu stecken.
Der Process synoscgi scheint bei allen Indizierungsvorgängen tief mit drin zu stecken.
Aus meiner Sicht kam das aus heiterem Himmel. Das begann mitten in der Nacht. Ich nutze die Box ausschließlich für cron-gesteuerte Backups auf rsnapshot- bzw. rsync-Basis. Ansonsten wird damit nichts gemacht. Updates stehen auf "manuell"
Ich finde nirgendwo eine Doku, was genau dieser Prozess eigentlich macht. Kein einzelner Prozess verursacht für sich eine hohe Load, es ist die schiere Menge, und die laufen alle mit "nice -10".
Ich finde nirgendwo eine Doku, was genau dieser Prozess eigentlich macht. Kein einzelner Prozess verursacht für sich eine hohe Load, es ist die schiere Menge, und die laufen alle mit "nice -10".
Dann versuch mal den Weg, den schon @himitsu vorgeschlagen hat. Ich tippe da evtl. auf "Universal Search" (SynoFinder), der da auf deinen Backups rumrutscht.
Mit "synopkg list --name" bekommst du eine Liste der Pakete, mit "synopkg stop SynoFinder" z.B. kannst du den SynoFinder stoppen. Evtl. stoppst du damit zwar auch davon abhängige Pakete wie SynologyDrive, aber was soll's. Kannst die später ja wieder starten.
Mit "synopkg list --name" bekommst du eine Liste der Pakete, mit "synopkg stop SynoFinder" z.B. kannst du den SynoFinder stoppen. Evtl. stoppst du damit zwar auch davon abhängige Pakete wie SynologyDrive, aber was soll's. Kannst die später ja wieder starten.
Zuletzt bearbeitet:
Wie bereits geschrieben, habe ich alle mit synopkg list gefundenen Prozesse gestoppt - kein Erolg. Der Hinweis auf "SynoFinder" klang gut, aber auch das hat die Situation nicht verbessert.
# synopkg stop SynoFinder
package SynoFinder stop successfully
Noch immer über 300 synoscgi- und über 30 query.cgi-Prozesse, Load liegt bei 40.
# synopkg stop SynoFinder
package SynoFinder stop successfully
Noch immer über 300 synoscgi- und über 30 query.cgi-Prozesse, Load liegt bei 40.
Ich würde vorschlagen, frag mal bei Synology nach.
synoscgi ist schon ein heißes Konstrukt. Der scheint unter Kontrolle von systemd zu laufen und stellt wohl seine "Dienste" allen möglichen Paketen/Prozessen zur Verfügung. Frage ist halt, welcher davon die Last verursacht. Schau dir das mal mit "ps -ef | grep synoscgi" an., vielleicht gibt das ja Aufschluss. Bei mir gibt es auch viele synoscgi-Prozesse, aber die erzeugen kaum Last. Bei vielen werden da "--mod"-Parameter aufgelistet, die wiederum meist auf Pakete schließen lassen.
Was läuft denn an Paketen bei dir alles noch?
synoscgi ist schon ein heißes Konstrukt. Der scheint unter Kontrolle von systemd zu laufen und stellt wohl seine "Dienste" allen möglichen Paketen/Prozessen zur Verfügung. Frage ist halt, welcher davon die Last verursacht. Schau dir das mal mit "ps -ef | grep synoscgi" an., vielleicht gibt das ja Aufschluss. Bei mir gibt es auch viele synoscgi-Prozesse, aber die erzeugen kaum Last. Bei vielen werden da "--mod"-Parameter aufgelistet, die wiederum meist auf Pakete schließen lassen.
Was läuft denn an Paketen bei dir alles noch?
Ich finde zahlreiche solche Prozesse:
15126 ? R<s 0:00 \_ /usr/syno/synoman/webapi/query.cgi TERM=vt102 LD_PRELOAD=openhook.so PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/syno/sbin:/usr/syno/bin:/usr/local/sbin:/usr/local/bin PWD=/ JOB=apparmor SHLVL=0 UPSTART_INSTANCE= UPSTART_EVENTS=syno.network.ready started SOCKET=/run/synoscgi.sock UPSTART_JOB=synoscgi INSTANCE= CONTENT_LENGTH= SCRIPT_FILENAME=/usr/syno/synoman/webapi/query.cgi SCRIPT_NAME=/webapi/query.cgi REQUEST_METHOD=GET REQUEST_URI=/webapi/query.cgi?api=SYNO.API.Info&version=1&method=query QUERY_STRING=api=SYNO.API.Info&version=1&method=query CONTENT_TYPE= DOCUMENT_URI=/webapi/query.cgi DOCUMENT_ROOT=/usr/syno/synoman SCGI=1 SERVER_PROTOCOL=HTTP/1.1 REQUEST_SCHEME=http GATEWAY_INTERFACE=CGI/1.1 SERVER_SOFTWARE=nginx/1.16.1 REMOTE_ADDR=192.168.178.9 REMOTE_PORT=37226 SERVER_ADDR=192.168.178.21 SERVER_PORT=5000 SERVER_NAME=192.168.178.21 PATH_INFO= HTTP_HOST=192.168.178.21:5000 HTTP_USER_AGENT=python-requests/2.25.0 HTTP_ACCEPT_ENCODING=gzip, deflate HTTP_ACCEPT=*/* HTTP_CONNECTION=keep-alive ENABLE_X_ACCEL_REDIRECT=yes
15126 ? R<s 0:00 \_ /usr/syno/synoman/webapi/query.cgi TERM=vt102 LD_PRELOAD=openhook.so PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/syno/sbin:/usr/syno/bin:/usr/local/sbin:/usr/local/bin PWD=/ JOB=apparmor SHLVL=0 UPSTART_INSTANCE= UPSTART_EVENTS=syno.network.ready started SOCKET=/run/synoscgi.sock UPSTART_JOB=synoscgi INSTANCE= CONTENT_LENGTH= SCRIPT_FILENAME=/usr/syno/synoman/webapi/query.cgi SCRIPT_NAME=/webapi/query.cgi REQUEST_METHOD=GET REQUEST_URI=/webapi/query.cgi?api=SYNO.API.Info&version=1&method=query QUERY_STRING=api=SYNO.API.Info&version=1&method=query CONTENT_TYPE= DOCUMENT_URI=/webapi/query.cgi DOCUMENT_ROOT=/usr/syno/synoman SCGI=1 SERVER_PROTOCOL=HTTP/1.1 REQUEST_SCHEME=http GATEWAY_INTERFACE=CGI/1.1 SERVER_SOFTWARE=nginx/1.16.1 REMOTE_ADDR=192.168.178.9 REMOTE_PORT=37226 SERVER_ADDR=192.168.178.21 SERVER_PORT=5000 SERVER_NAME=192.168.178.21 PATH_INFO= HTTP_HOST=192.168.178.21:5000 HTTP_USER_AGENT=python-requests/2.25.0 HTTP_ACCEPT_ENCODING=gzip, deflate HTTP_ACCEPT=*/* HTTP_CONNECTION=keep-alive ENABLE_X_ACCEL_REDIRECT=yes
Welcher Befehl gibt das aus?
Wenn wir davon ausgehen, dass synoscgi ein API-Dienst ist, gilt es herauszufinden, wer den benutzt (extern oder DS-intern).
Da tauchen doch IPs auf (192.168.178.9, 192.168.178.21), .21 dürfte die DS sein. Wer ist .9?
Wenn wir davon ausgehen, dass synoscgi ein API-Dienst ist, gilt es herauszufinden, wer den benutzt (extern oder DS-intern).
Da tauchen doch IPs auf (192.168.178.9, 192.168.178.21), .21 dürfte die DS sein. Wer ist .9?
REQUEST_URI=/webapi/query.cgi?api=SYNO.API.Info&version=1&method=query
192.168.178.9 könnte auch eine VM oder Docker sein, oder halt jemand Externes.
Jedenfalls irgendwer, der hier einen Status der DS abfragt.
Das selber sollte aber keine große Last verursachen, da es eigentlich nichts macht.
192.168.178.9 könnte auch eine VM oder Docker sein, oder halt jemand Externes.
Jedenfalls irgendwer, der hier einen Status der DS abfragt.
Das selber sollte aber keine große Last verursachen, da es eigentlich nichts macht.
Sozusagen leider hat sich das Problem gelöst, ohne daß ich eine klare Ursache finden konnte. Die oben erwähnte IP 192.168.178.9 ist ein Homeassistant, der die Bilder einer Webcam von dem NAS holt. Das besteht schon seit Monaten so, ohne daß es zu Auffälligkeiten kam. Ein paar Minuten (weniger als 10) nach Herunterfahren des Homeassistant war der Spuk auf dem NAS vorbei, die Prozesse verschwanden. Allerdings kann ich das nicht sicher darauf zurückführen. Nach Wiederhochfahren des Homeass. trat das Problem nicht wieder auf. Es besteht also die Möglichkeit, daß das irgendetwas anderes war und nur ein zufälliger zeitlicher Zusammenhang vorlag. Unschön, das ist ein nicht konstanter und nicht reproduzierbarer Fehler.
Kaffeautomat
Wenn du das Forum hilfreich findest oder uns unterstützen möchtest, dann gib uns doch einfach einen Kaffee aus.
Als Dankeschön schalten wir deinen Account werbefrei.
