hmm, es wurden nach 2.6.7 aenderungen an ip_route_input_slow gemacht - aber ob das was mit dem crash hier zu tun hat ist fraglich. ich wuerde ein kernel-update machen und wenn es dann immer noch probleme gibt das RAM testen bzw gleich austauschen lassen - insb wenn der naechste crash komplett andere fehlermeldungen verursacht..
@samuel: ferndiagnosen ohne zugriff auf OS und hardware und ohne irgendwelche hintergrundinformation sind offensichtlicherweise niemals ‘_genau_’. wenn du deinem kfz-mechaniker am telefon nur sagst ‘mein auto springt nicht an’ wird er dir wohl auch kaum sagen koennen, wo das problem liegt..
die verwendete kernel-version waere schon recht hilfreich (’uname -a’ in der shell)..
oder den sshd auf nen anderen port verlegen. bisher vesuchen es die kiddies nur auf port 22. angenehmer nebeneffekt: weniger muell in den logfiles, dann macht das logfile-lesen wieder richtig spass..;)
wenn der kenrel einigermassen up-2-date ist (zb nicht jener oben erwaehnte 2.4.19) wuerd ich - falls moeglich - mal das RAM mit memtest86+ (http://www.memtest.org/, nicht verwechseln mit dem nicht mehr maintainten memtest86 auf http://www.memtest86.com/) einem stress-test unterziehen. ich hatte schon oefters das ein defektes speichermodul mir sporadisch den kernel crashen lies, einmal sogar mit korrupten userdaten auf der festplatte..sehr unfein..
allerdings dauert der test recht lange und der server ist deshalb fuer einige stunden offline..
gibts sonst irgendwelche seltsamen (evtl auch vollkommen unrelated erscheineneden) log-eintraege? hat sich die maschine evtl vorher schon manchmal ’seltsam’ verhalten? sind RAM (ECC?) und festplatten ok?
07
hmm, es wurden nach 2.6.7 aenderungen an ip_route_input_slow gemacht - aber ob das was mit dem crash hier zu tun hat ist fraglich. ich wuerde ein kernel-update machen und wenn es dann immer noch probleme gibt das RAM testen bzw gleich austauschen lassen - insb wenn der naechste crash komplett andere fehlermeldungen verursacht..
06
@samuel: ferndiagnosen ohne zugriff auf OS und hardware und ohne irgendwelche hintergrundinformation sind offensichtlicherweise niemals ‘_genau_’. wenn du deinem kfz-mechaniker am telefon nur sagst ‘mein auto springt nicht an’ wird er dir wohl auch kaum sagen koennen, wo das problem liegt..
die verwendete kernel-version waere schon recht hilfreich (’uname -a’ in der shell)..
05
oder den sshd auf nen anderen port verlegen. bisher vesuchen es die kiddies nur auf port 22. angenehmer nebeneffekt: weniger muell in den logfiles, dann macht das logfile-lesen wieder richtig spass..;)
04
wenn der kenrel einigermassen up-2-date ist (zb nicht jener oben erwaehnte 2.4.19) wuerd ich - falls moeglich - mal das RAM mit memtest86+ (http://www.memtest.org/, nicht verwechseln mit dem nicht mehr maintainten memtest86 auf http://www.memtest86.com/) einem stress-test unterziehen. ich hatte schon oefters das ein defektes speichermodul mir sporadisch den kernel crashen lies, einmal sogar mit korrupten userdaten auf der festplatte..sehr unfein..
allerdings dauert der test recht lange und der server ist deshalb fuer einige stunden offline..
03
die ssh-attacken sind nur ‘normales’ hintergrundrauschen..ich nehm an, dass sie nicht erfolgreich waren und kein login erfolgt ist?
02
gibts sonst irgendwelche seltsamen (evtl auch vollkommen unrelated erscheineneden) log-eintraege? hat sich die maschine evtl vorher schon manchmal ’seltsam’ verhalten? sind RAM (ECC?) und festplatten ok?
01
was ist das den fuer ne kernelversion?