Moin, hab hab hier seit einer guten Woche sehr komische Prozesse auf meinem Server ( s. Anhang ) und ich weis nicht woher die kommen könnten. Ich hab nur eine weitere Kamera zu Zoneminder hinzugefügt und seit dem habe ich diese enorme CPU Last, selbst wenn zoneminder heruntergefahren wird laufen die u.g. Prozesse einfach weiter. Apache / PHP etc sämtliche Dienste neu starten hilft nichts. Ich laß, das der Prozeß "ionclean" etwas mit PHP zu tun hat.
Ein SSH Login dauert fast 2-3 Minuten, das Aufrufen von htop ebenfalls. (ionclean) und (install) kann ich zwar mit kill beenden aber keine 10 sek später sind die Prozesse wieder da und lasten jeweils einen Kern zu 100% aus.Wie kann ich herausfinden was die Prozesse gestartet hat und warum die Prozesse nicht durchlaufen bzw. so eine hohe CPU Last erzeugen ?
Hohe CPU Last durch "komische" Prozesse
Hohe CPU Last durch "komische" Prozesse
Zuletzt geändert von speefak am 27.10.2023 10:13:11, insgesamt 2-mal geändert.
- whisper
- Beiträge: 3194
- Registriert: 23.09.2002 14:32:21
- Lizenz eigener Beiträge: GNU Free Documentation License
-
Kontaktdaten:
Re: Hohe CPU Last durch "komische" Prozesse
ich würde mal mit strace -p an die fraglichen prozesse andocken und schauen, welche aktivitäten das sind. Oft entdeckt man den eigentlichen Verursacher leichter
Re: Hohe CPU Last durch "komische" Prozesse
Nach einem remove --purge udisks2 habe ich nun eine Prozeß der udiskd abgelöst hat aber weiterhin eine ganze CPU Kern auslastet
Re: Hohe CPU Last durch "komische" Prozesse
Code: Alles auswählen
journalctl -f
Re: Hohe CPU Last durch "komische" Prozesse
"strace -p PID" bringt etwas Licht ins Dunkel Alles was nicht auf die SSD/HDD zugreift läuft fix, sobald SSD/HDD Operationen anstehen dauert alles ewig. Ich hatte mit nmon schon mal nach der Diskauslastung geschaut und nix auffälliges gefunden. Mit strace, denke ich, habe ich das "Amok Script" gefunden.
Re: Hohe CPU Last durch "komische" Prozesse
Problem gefunden: Eine interne Skriptabfrage funktionierte nicht mehr sodass ein und derselbe mount--bind alle 10 Minuten ausgeführt wurde.
Ich hatte ein Skript geschrieben, dass alle 10 Minuten prüft ob bestimmte Verzeichnisse per mount-bind eingebunden sind. Mount bind daher, das es u.a. mit versch. Clients/Programmen nicht möglich ist eine SSH Freigabe mit der Option -follow_symlinks und -ro zu nutzen ( Windows, PHP Virtualbox, Nextcloud u.a. ).
Oder besteht die Möglichkeit mit OS Mitteln, wie beispielsweise über die fstab Verzeichnisse mit o.g. Optionen einzubinden und das System bei Fehlern beim Boot nicht stoppt.
Sprich:
1 OS bootet
2 Skript mountet Verzeichnisse mit mount Optionen
3 Webserver u.a. Dienste mit Zugriff auf o.g. Verzeichnisse werden gestartet
Ich hatte ein Skript geschrieben, dass alle 10 Minuten prüft ob bestimmte Verzeichnisse per mount-bind eingebunden sind. Mount bind daher, das es u.a. mit versch. Clients/Programmen nicht möglich ist eine SSH Freigabe mit der Option -follow_symlinks und -ro zu nutzen ( Windows, PHP Virtualbox, Nextcloud u.a. ).
Oder besteht die Möglichkeit mit OS Mitteln, wie beispielsweise über die fstab Verzeichnisse mit o.g. Optionen einzubinden und das System bei Fehlern beim Boot nicht stoppt.
Sprich:
1 OS bootet
2 Skript mountet Verzeichnisse mit mount Optionen
3 Webserver u.a. Dienste mit Zugriff auf o.g. Verzeichnisse werden gestartet
- Livingston
- Beiträge: 1462
- Registriert: 04.02.2007 22:52:25
- Lizenz eigener Beiträge: MIT Lizenz
- Wohnort: 127.0.0.1
Re: Hohe CPU Last durch "komische" Prozesse
Versuch's mal mit der Option nofail bei den fstab-Optionen.speefak hat geschrieben:27.10.2023 16:52:42Oder besteht die Möglichkeit mit OS Mitteln, wie beispielsweise über die fstab Verzeichnisse mit o.g. Optionen einzubinden und das System bei Fehlern beim Boot nicht stoppt.
man fstab hat geschrieben:nofail Keine Fehler für dieses Gerät melden, wenn es nicht existiert.
Der Hauptunterschied zwischen etwas, was möglicherweise kaputtgehen könnte und etwas, was unmöglich kaputtgehen kann, besteht darin, dass sich bei allem, was unmöglich kaputtgehen kann, falls es doch kaputtgeht, normalerweise herausstellt, dass es unmöglich zerlegt oder repariert werden kann.
Douglas Adams
Douglas Adams