On 01-Jun-00 Bjoern Krombholz wrote:

Hendrik Sattler wrote:

...

kann es sein, dass die Standard-SuSE-Cronjobs das System (K6-2-350) so stark belasten, das nichts mehr geht? Eben fing meine HDD ganz unmotiviert an zu rödeln. Nicht mal Numlock ließ sich unter X noch ein-/ausschalten, der Mousezeiger bewegte sich aber noch, nur mit minutenlanger Verspätung. Die Internetseite im Netscape war auch schon seit ein paar Minuten da und enthält keine aktiven Inhalte irgendwelcher Art. War auch das erste mal. Nach einem Kaltstart :-((( (ging nicht mehr anders), hat er nur eine inode mit falscher dtime gefunden.

Was soll ich nun davon halten. Darf ein Prozess soviel Rechenleistung belegen, so daß wirklich nichts mehr geht?

Du hättest den Rechner nicht ausschalten müssen - irgenwann wäre der cron job zum ende gekommen, je nachdem, wie groß/schnell die Platte ist.

Wie lange würdest du auf einen cron-job warten? nach 15min Unfähigkeit, den Mauszeiger zu bewegen, hats mir gereicht.

Wenn fast gar nichts mehr ging, hört sich das ganz danach an, als ob deine Platten nicht mit DMA laufen, also jeder Zugriff ne Menge CPU-Last erzeugt (um es einfach auszudrücken). Welches Board/Chipsatz hast du? Ich könnte dann mal gucken, was sich da machen läßt.

Laut hdparm schon. Ist im BIOS eingeschaltet, Default_DMA ist im Kernel angeschaltet. Das hier ist ein VIA MVP3-Chipsatz. Die HDD kann das auch. Hendrik Sattler --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com

Joerg Zimmermann schrieb am Donnerstag den 01. Juni 2000:

Ich hatte das gleich Prob bei uns. In dem cron.daily wurde bei uns ein manpath aufgerufen. Das hat den Rechner ganz schoen beschaeftigt. Mach doch mal ein top wenn die Festplatte wieder anfaengt zu roedeln, dann muesste der schuldige Process zu sehen sein.

Ich beobachte das hier auch und konnte noch keine Lösung finden :( Als "Schuldigen" konnte ich bis jetzt folgendes ausmachen: - security-daily.sh ruft csh auf und läd per source /etc/csh.cshrc - in csh.cshrc steht dann setenv MANPATH "`(unsetenv MANPATH; manpath -q)`" - manpath steht nach einer weile bei knapp 100%-cpu-last und macht nichts mehr... Weis jemand, warum sich manpath / csh im non-interactive mode aufhängt? Gruß Jens -- registered linux user #130250 --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com

Das Problem kann ich auch bestätigen. Eine Lösung habe ich auch bisher nicht gefunden, aber durch deinstallieren des entprechenden Pakets (security-Skripte, serie sec), werden diese Skripte bei uns (natürlich) nicht mehr ausgeführt. Problem nicht gelöst, aber weg. Aber wenn man sie unbedingt braucht... JLT Jens Tautenhahn wrote:

Joerg Zimmermann schrieb am Donnerstag den 01. Juni 2000:

...

Ich hatte das gleich Prob bei uns. In dem cron.daily wurde bei uns ein manpath aufgerufen. Das hat den Rechner ganz schoen beschaeftigt. Mach doch mal ein top wenn die Festplatte wieder anfaengt zu roedeln, dann muesste der schuldige Process zu sehen sein.

Ich beobachte das hier auch und konnte noch keine Lösung finden :(

Als "Schuldigen" konnte ich bis jetzt folgendes ausmachen: - security-daily.sh ruft csh auf und läd per source /etc/csh.cshrc - in csh.cshrc steht dann setenv MANPATH "`(unsetenv MANPATH; manpath -q)`" - manpath steht nach einer weile bei knapp 100%-cpu-last und macht nichts mehr...

Weis jemand, warum sich manpath / csh im non-interactive mode aufhängt?

Gruß Jens

-- registered linux user #130250

--------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com

--------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com