seltsamer find-prozess legt system lahm
Hallo, mein Webserver (Suse 8.0) legt seit gestern Abend ein seltsames Verhalten an den Tag. Zum einen dauert es enorm lange bis Verbindungen zu Webserver und SSH aufgebaut werden. Will ich mich beispielsweise per SSH einloggen warte ich ca. 20 Sekunden auf eine Antwort, sobald ich das Passwort übergebe läuft alles in gewohntem Tempo. Ähnlich ist es mit dem (Apache-)Webserver. Es dauert einige Zeit bis der Server auf anfragen reagiert, liefert die Daten dann aber problemlos aus. FTP-Verbindungen laufen dagegen ohne Probleme. Ich konnte keine Hinweise in irgendwelchen Logs finden, die auf ein Problem hindeuten. Was mir aber viel mehr Sorgen macht ist ein mir rätselhafter Prozess, der das System restlos auslastet (und den ich nur deswegen per top entdeckt habe). Hier einmal die Ausgabe von ps f p 16187: UID PID PPID C STIME TTY TIME CMD nobody 16187 16184 94 00:17 ? 03:39:04 /usr/bin/find / ( -fstype nfs -o -fstype NFS -o -fstype proc -o -fstype afs -o -fstype smbfs -o -fstype autofs -o -type d regex \(^/mnt$\)\|\(^/cdrom$\)\|\(^/tmp$\)\|\(^/usr/tmp$\)\|\(^/var/tmp$\)\|\( ^/var/spool$\)\|\(^/proc$\)\|\(^/media$\) ) -prune -o print Ich befürchte, dass das ein Sicherheitsproblem ist. Ich kann den Prozess nicht killen, er läuft einfach weiter. Daher habe ich die Kiste erstmal rebootet, allerdings tauchte der Prozess mit gleichem Kommando nach ein paar Stunden erneut auf (die obige Ausgabe stammt vom Zeiten Auftreten). Nach einem weiteren Reboot ist zumindest erstmal wieder weg. Bin ich einfach nur paranoid oder ist da am ende gar jemand in meinen Server eingebrochen? Jan Harder
Am Freitag, 27. Dezember 2002 05:34 schrieb Jan Harder: Moin Jan,
Bin ich einfach nur paranoid oder ist da am ende gar jemand in meinen Server eingebrochen? ja, Du bist paranoid ;-)
Das ist (vermutlich) ein cronjob der täglich ausgeführt wird und die Datenbank für das Kommando locate füllt. bis denn ... /Frank/
Hallo,
Moin Jan,
Das ist (vermutlich) ein cronjob der täglich ausgeführt wird und die Datenbank für das Kommando locate füllt.
ok, es wird wohl updatedb sein, hätte ich vielleicht auch selbst drauf kommen können. Offenbar ist das Ding gestern wirklich 17 Stunden lang gelaufen und mir deswegen suspekt vorgekommen, als es mir am späten Nachmittag in top begegnete. Ich habe updatedb eben einmal von Hand angeschmissen und wohl den Grund dafür gefunden: simzone:~ # updatedb /usr/bin/find: /websites/simszone/Files/diesims/floors/floïr143.png: No such file or directory /usr/bin/find: /websites/simszone/Files/diesims/floors/floïr143.png: No such file or directory /usr/bin/find: /websites/simszone/Files/diesims/floors/floïr143.png: No such file or directory /usr/bin/find: /websites/simszone/Files/diesims/floors/floïr143.png: No such file or directory /usr/bin/find: /websites/simszone/Files/diesims/floors/floïr143.png: No such file or directory /usr/bin/find: /websites/simszone/Files/diesims/floors/floïr143.png: No such file or directory Die Datei über die er sich da beschwert hieß eigentlich floor143.png (falls sich jemand wundert: anstatt des zweiten "o" steht da ein "i" mit zwei Punkten - vielleicht sieht das auf anderen Systemen anders aus, bin mir da nicht sicher). Nach dieser Ausgabe scheint sich find aufzuhängen und dabei fortwährend über 90% der Rechenleistung für sich zu beanspruchen. Es läuft nun schon über 30 Minuten und da sollte es ja eigentlich längst fertig sein (zumindest läuft es sonst nicht so lange). Ich hab dann mal folgendes versucht: simzone:/websites/simszone/Files/diesims/floors # ls ls: floïr143.png: No such file or directory . floor031.png floor128.png floor173.png floor56.png .. floor032.png floor129.png floor174.png floor57.png Das ist nicht das erste mal, dass ich solche Zeichenverdreher sehe. Vor einiger Zeit lieferte ein PHP-Script aus heiterem Himmel einen Fehler - der Grund war, dass sich ohne das Zutun irgendeines Users ein einzelnes Zeichen darin in ein kryptisches Zeichen verwandelt hatte. Ich hatte deswegen schon einmal hier nachgefragt, leider wusste aber niemand Rat. Das PHP-Script konnte ich einfach korrigieren, aber was mache ich mit der Datei? Ich kann da ja nicht mehr drauf zugreifen: simzone:/websites/simszone/Files/diesims/floors # mv flo?r143.png floor143.png mv: cannot stat `floïr143.png': No such file or directory Ich hätte kein Problem damit das Ding einfach zu löschen, ich weiß nur nicht wie. Hat jemand eine Idee? Schon mal danke, Jan PS: Sorry Frank, hatte die erste Mail versehentlich nur an dich gesendet.
Hy, Am 02/12/27@06:40 schrieb Jan Harder:
Moin Jan,
Ich hab dann mal folgendes versucht:
simzone:/websites/simszone/Files/diesims/floors # ls ls: floïr143.png: No such file or directory . floor031.png floor128.png floor173.png floor56.png .. floor032.png floor129.png floor174.png floor57.png
simzone:/websites/simszone/Files/diesims/floors # mv flo?r143.png floor143.png mv: cannot stat `floïr143.png': No such file or directory
Ich hätte kein Problem damit das Ding einfach zu löschen, ich weiß nur nicht wie. Hat jemand eine Idee?
Was fuer ein Dateisystem? Ich hatte vor einer ganzen Weile mal aehnliche Probleme mit Dateien, die Umlaute enthielten auf einem reiserfs. -- bye maik
On Fre, 27 Dez 2002 at 06:40 (+0100), Jan Harder wrote: [...]
Das PHP-Script konnte ich einfach korrigieren, aber was mache ich mit der Datei? Ich kann da ja nicht mehr drauf zugreifen:
simzone:/websites/simszone/Files/diesims/floors # mv flo?r143.png floor143.png mv: cannot stat `floïr143.png': No such file or directory
Ich hätte kein Problem damit das Ding einfach zu löschen, ich weiß nur nicht wie. Hat jemand eine Idee?
Versuch doch mal, alle anderen Dateien in ein neues Verzeichnis zu verschieben und dann per rm -r das kaputte Verzeichnis zu löschen. Jan
*** Jan Harder (jan@simszone.de) schrieb in suse-linux heute:
[...] Bin ich einfach nur paranoid oder ist da am ende gar jemand in meinen Server eingebrochen?
Ein pstree ("rpm -qil ps") hätte Dir unmittelbar gesagt, dass dieser Prozess von "updatedb" und dieser wiederum letztlich von cron gestartet worden ist. Weiterungen, insbesondere die, dass das nichts mich einem cracker zu tun hat, kann man sich selbst erschließen. MG Henning Hucke -- How many bits would a BitBlit blit if a BitBlit could blit bits? -- macanespie@waves.pas.ti.com in <1993Nov16.130625.1@waves.pas.ti.com>
Moin, Jan Harder:
Verhalten an den Tag. Zum einen dauert es enorm lange bis Verbindungen zu Webserver und SSH aufgebaut werden. Will ich mich beispielsweise per SSH einloggen warte ich ca. 20 Sekunden auf eine Antwort, sobald ich das
Wahrscheinlich eine reverse DNS-Auflösung, die nicht funktioniert. Client startet Anfrage an Server. Server will besonders hübsches Logfile schreiben und versucht, den Namen zu ermitteln, der hinter ip-von-Client steckt. Das geht irgendwo in die Hose, dauert aber sehr lange. Nachdem dem Server das klar geworden ist, unterlässt er solche Anfragen auf diese IP. Erstmal. Daher kommen die Daten dann "normal". ...bis zum nächsten Mal, einige Zeit später. Lösung a (Modell Schraube mit der Zange in die Wand kloppen): Stell allen möglichen Serverprogrammen dieses Verhalten ab. Lösung b (Modell "Cooler Sysadmin mit Sonnenbrille): Stell sicher, daß die Reversauflösung anständig funktioniert. Ja nach Struktur deines Problems durch einen lokalen DNS oder einträge in /etc/hosts. Gruß, Ratti -- http://www.gesindel.de Fontmanagement for Linux fontlinge Schriftenverwaltung fuer Linux
Moin,
Wahrscheinlich eine reverse DNS-Auflösung, die nicht funktioniert. Client startet Anfrage an Server. Server will besonders hübsches Logfile schreiben und versucht, den Namen zu ermitteln, der hinter ip-von-Client steckt. Das geht irgendwo in die Hose, dauert aber sehr lange.
Exakt das war es, ist mir vor ca. 10 Minuten aufgefallen als ich festellte, dass ein wget <insert-any-domain-here> mit einem Resolving <insert-any-domain-here>... failed: Host not found. quittiert wurde. Die IP des DNS-Servers hatte sich geändert und mein Host hat mir das ganze nicht mitgeteilt. Trotzdem vielen Dank Jörg. Jan
participants (6)
-
Frank Röske -
Henning Hucke -
Jan Harder -
Jan.Trippler＠t-online.de -
Jörg Roßdeutscher -
Maik Holtkamp