Hallo, mir ist es neulich passiert, daß meine /var-Partition durch exzessives Logging vollgeschrieben wurde. Dadurch war u.a. Effekten derjenige, daß man sich am kdm nicht mehr anmelden konnte. Hierzu ein kleiner, aber entscheidender Auszug aus /var/log/messages: Jun 19 19:47:09 xtal kernel: floppy0: disk absent or changed during operation Jun 19 19:47:09 xtal kernel: end_request: I/O error, dev 02:00 (floppy), sector 2078 Jun 19 19:47:09 xtal kernel: device Jun 19 19:47:09 xtal kernel: 02:00: rw=0, want=1039, limit=4 Jun 19 19:47:09 xtal kernel: attempt to access beyond end of device Jun 19 19:47:09 xtal kernel: 02:00: rw=0, want=1039, limit=4 Jun 19 19:47:09 xtal kernel: attempt to access beyond end of device Jun 19 19:47:09 xtal kernel: 02:00: rw=0, want=1039, limit=4 Jun 19 19:47:09 xtal kernel: attempt to access beyond end of device Jun 19 19:47:09 xtal kernel: 02:00: rw=0, want=1039, limit=4 Jun 19 19:47:09 xtal kernel: attempt to access beyond end of device ... und so geht das ca. 5 Mio. Zeilen weiter so (immer die letzten zwei Zeilen). Ok, die Ursache wird ja gesagt. Wahrscheinlich habe ich die Floppy entfernt, ohne vorheriges umount /floppy - kleine Ursache, große Wirkung :-( Was mich nun interessieren würde, ist aber, wie das überhaupt so weit gehen kann, daß der Kernel hier scheinbar endlose Schreibversuche unternimmt. Irgendwann sollte der Kernel doch aufgeben, oder? (Ich habe übrigens noch die Version 2.4.10-4GB von der SuSE 7.3.) Jedenfalls finde ich, daß durch solch eine Kleinigkeit die Arbeit des Systems nicht derart massiv beeinflussbar sein sollte. Kann man die Logging-Freudigkeit irgendwie sinnvoll einschränken? Wie sind denn hierzu die Expertenmeinungen? Ich werde mir als Konsequenz jedenfalls ein Skript schreiben, daß regelmäßig die Befüllung aller wichtigen Partitionen überwacht und ggf. eine Warn-Mail an den Admin schickt. Was mich noch interessieren würde: Wie kann man verhindern, daß ein amoklaufender Prozess den Speicher zumüllt und dann durch exzessives Paging das System völlig inreaktiv wird (ist mir vor Jahren einmalig mit einem KDE-Programm passiert)? Kann man irgendwie die Speicherbelegung begrenzen? Danke für Eure geschätzten Meinungen und Vorschläge! Gruß, Thomas
Am Dienstag, 1. Juli 2003 20:21 schrieb Thomas Michalka: Hallo Thomas
Hallo,
mir ist es neulich passiert, daß meine /var-Partition durch exzessives Logging vollgeschrieben wurde. Dadurch war u.a. Effekten derjenige, daß man sich am kdm nicht mehr anmelden konnte. [...] Was mich nun interessieren würde, ist aber, wie das überhaupt so weit gehen kann, daß der Kernel hier scheinbar endlose Schreibversuche unternimmt. Irgendwann sollte der Kernel doch aufgeben, oder? (Ich habe übrigens noch die Version 2.4.10-4GB von der SuSE 7.3.)
Setzte mal den Loglevel des syslogd ein wenig herunter. Da du SuSE 7.3 verwendest, sollte die Einstellung irgendwo in der /etc/rc.config bzw. möglicherweise auch in einer Datei im Verzeichnis /etc/rc.config.d zu machen sein. Kann dir im Moment leider nichts genaueres sagen, da ich hier keine SuSE 7.x laufen habe. Vielleicht hilft das aber trotzdem weiter. Andererseits könntest du auch einen Cronjob schreiben, der z.B. alle 30 Minuten die Größe der Logfiles überprüft und gegebenenfalls komprimiert bzw. die älteren ganz löscht. [...]
Was mich noch interessieren würde: Wie kann man verhindern, daß ein amoklaufender Prozess den Speicher zumüllt und dann durch exzessives Paging das System völlig inreaktiv wird (ist mir vor Jahren einmalig mit einem KDE-Programm passiert)? Kann man irgendwie die Speicherbelegung begrenzen?
Ja, das geht läßt sich mit 'ulimit' machen, siehe auch http://sdb.suse.de/de/sdb/html/mfrueh_ulimit.html
Danke für Eure geschätzten Meinungen und Vorschläge!
viele Grüße, sam
Hallo Sam, Samuel Edlmeier schrieb:
Am Dienstag, 1. Juli 2003 20:21 schrieb Thomas Michalka: Hallo Thomas
Hallo,
mir ist es neulich passiert, daß meine /var-Partition durch exzessives Logging vollgeschrieben wurde. Dadurch war u.a. Effekten derjenige, daß man sich am kdm nicht mehr anmelden konnte.
[...]
Was mich nun interessieren würde, ist aber, wie das überhaupt so weit gehen kann, daß der Kernel hier scheinbar endlose Schreibversuche unternimmt. Irgendwann sollte der Kernel doch aufgeben, oder? (Ich habe übrigens noch die Version 2.4.10-4GB von der SuSE 7.3.)
Setzte mal den Loglevel des syslogd ein wenig herunter.
Vielleicht hilft das, aber das wäre dennoch nur ein Herumdoktern am Symptom. Vielleicht kann man dem Kernel beim Booten Parameter mit geben, die bewirken, daß der Kernel fortgesetzt erfolglose Aktionen sowohl in der Wiederholrate, als auch in der absoluten Häufigkeit begrenzt? Wäre möglicherweise auch gut geeignet gegen Denial-of-Service-Attacken :-)
Da du SuSE 7.3 verwendest, sollte die Einstellung irgendwo in der /etc/rc.config bzw. möglicherweise auch in einer Datei im Verzeichnis /etc/rc.config.d zu machen sein. Kann dir im Moment leider nichts genaueres sagen, da ich hier keine SuSE 7.x laufen habe. Vielleicht hilft das aber trotzdem weiter.
Zunächst habe ich die folgende Passage gefunden: # Default loglevel for klogd # KERNEL_LOGLEVEL="1" # # if not empty: parameters for syslogd # for example SYSLOGD_PARAMS="-r -s my.dom.ain" # SYSLOGD_PARAMS="" Wenn ich jetzt den Loglevel noch heruntersetze, wird wohl gar nichts mehr geloggt ;-), oder? Mich würde noch mehr interessieren, was die Parameter für den syslogd bedeuten. Wo könnte das dokumentiert sein? (Naja, ich suche mal, die SuSE-Skripten nach der Benutzung dieser Umgebungsvariablen durch, dann werde ich schon das Kommando finden, dem diese Parameter übergeben werden.)
Andererseits könntest du auch einen Cronjob schreiben, der z.B. alle 30 Minuten die Größe der Logfiles überprüft und gegebenenfalls komprimiert bzw. die älteren ganz löscht.
Hmmm - das tut eigentlich schon ein SuSE-Cronjob, alle 24 h soviel ich weiß. Aber wie man sieht, kann es sein, daß das nicht ausreicht. Selbst, wenn man das durch ein Skript im Verzeichnis cron.hourly überprüfen läßt, reicht das nicht. Ich denke deshalb, daß die Überprüfung des Partitions-Füllgrads jede Minute ein guter Ansatz ist. Natürlich muß man dann auch die Größe einzelner Dateien (die üblichen Verdächtigen bevorzugt) überprüfen, sowie deren Wachstumsrate, um automatisierte Gegenmaßnahmen ergreifen zu können.
Kann man irgendwie die Speicherbelegung begrenzen?
Ja, das geht läßt sich mit 'ulimit' machen, siehe auch http://sdb.suse.de/de/sdb/html/mfrueh_ulimit.html
Sehr schön, danke. Das hilft schon mal, wenn man praktisch alleiniger Systemnutzer ist, bzw. wenn alle Benutzer so vernünftig sind, einen entsprechenden Eintrag in die ~/.bashrc zu machen. Aber man kann die Limits mit ulimit leider nicht selektiv für bestimmte Programme einstellen. Auch geht es nur für von der bash gestartete Prozesse (also auch nur für die eigenen). Wird die jeweilige Beschränkung auch an Kindprozesse eines Prozesses und wiederum an deren Kinder, u.s.w. vererbt?. Wie kann man systemweit Nutzngsbeschränkungen verfügen? Vielleicht ulimit in der /etc/profile - aber muß die jeder Benutzer von der ~/.bashrc unbedingt einlesen lassen (test -z "$PROFILEREAD" && . /etc/profile)? Wohl nicht, ein Benutzer kann das Einlesen leicht verhindern. Wie also systemweit Beschränkungen erzwingen (ähnl. quota f. Plattennutzung)? Wäre schön, wenn mir da noch jemand auf die Sprünge helfen könnte. Schöne Grüße, Tom
Hallo Thomas, hallo Leute, Am Montag, 7. Juli 2003 11:21 schrieb Thomas Michalka: [...]
Wie kann man systemweit Nutzngsbeschränkungen verfügen? Vielleicht ulimit in der /etc/profile - aber muß die jeder Benutzer von der ~/.bashrc unbedingt einlesen lassen (test -z "$PROFILEREAD" && . /etc/profile)? Wohl nicht, ein Benutzer kann das Einlesen leicht verhindern. Wie also systemweit Beschränkungen erzwingen (ähnl. quota f. Plattennutzung)?
Wäre schön, wenn mir da noch jemand auf die Sprünge helfen könnte.
gibt es einen Unterschied zwischen NAT und Masquerading? Ja, bei "Masquerading" vertippe ich mich laufend, deshalb schreibe ich
Ungetestet, sollte aber funktionieren: Gib den Usern als Loginshell nicht /bin/bash, sondern ein kleines Script #!/bin/bash ulimit [...] bash # [1] Das lässt sich dann wohl nicht umgehen ;-) Gruß Christian Boltz [1] Evtl. kannst Du auch "exec bash" verwenden, das spart einen laufenden Prozess ein ;-) -- lieber "NAT". [> Thorsten Haude und Patrick Hess in suse-linux]
* Thomas Michalka schrieb am Montag, 2003-07-07:
Aber man kann die Limits mit ulimit leider nicht selektiv für bestimmte Programme einstellen. Auch geht es nur für von der bash gestartete Prozesse (also auch nur für die eigenen). Wird die jeweilige Beschränkung auch an Kindprozesse eines Prozesses und wiederum an deren Kinder, u.s.w. vererbt?.
Ja.
Wie also systemweit Beschränkungen erzwingen (ähnl. quota f. Plattennutzung)?
less /usr/share/doc/packages/pam/modules/README.pam_limits -- Christian Ullrich Registrierter Linux-User #125183 "Remember: 'I am a person. I have a right to the ball.'"
participants (4)
-
Christian Boltz -
Christian Ullrich -
Samuel Edlmeier -
Thomas Michalka