Server abgeschmiert

[danu]

Code: Select all

Jul 30 21:14:40 s15180xxx kernel: c0162a78
Jul 30 21:14:40 s15180xxx kernel: Modules linked in: sg ide_cd cdrom speedstep_lib freq_table thermal processor fan dm_mod
Jul 30 21:14:40 s15180xxx kernel: EIP:    0060:[<c0162a78>]    Not tainted VLI
Jul 30 21:14:40 s15180xxx kernel: EFLAGS: 00010046   (2.6.17.5-060712a #1) 
Jul 30 21:14:41 s15180xxx kernel:  BUG: events/0/8, lock held at task exit time!
Jul 30 21:14:41 s15180xxx kernel:  [c0464a40] {cache_chain_mutex}
Jul 30 21:14:41 s15180xxx kernel: .. held by:          events/0:    8 [c1950030, 110]
Jul 30 21:14:41 s15180xxx kernel: ... acquired at:               cache_reap+0x11/0x1b0

Danach ging nichts mehr. Ich machte ein Hardware Reset, dann lief alles wieder OK.

S&P RootStart (Root Server)
SuSE 9.3 Linux Kernel 2.6.17.5-060712a

In den übrigen Logfiles entdeckte ich nichts ausssergewöhnliches, ausser dass von diesem Zeitpunkt an keine Einträge mehr standen.

Da ich erst vor einer halben Stunde darauf aufmeksam gemacht wurde, hatte ich noch keine Zeit zum googeln (wird nachgeholt), und falls jemand weiss, wo hier der Fehler liegt, wäre ich für jeden Tip dankbar.
Gruss, danu

[captaincrunch]

Wenn du den kopmpletten Oops gepostet hätte, wäre eine Analyse des Problems einfacher.

[danu]

Ja, ist wohl so oder so schwierig zu dieser seltenen Kernelmeldung einen Kontext zu finden. Googeln hat nicht viel mehr gebracht, als was man aus dieser Kernelmeldung schliessen könnte: ev. ein Bug und/oder ein Problem mit dem Hardwaremanagement. Das boot.msg Logfile wurde beim Hardwarerebooten natürlich überschrieben. Hatte keine andere Wahl. Die Kiste war völlig weg und es musste schnell was passieren. Logo hätte ja zuerst das Recovery System und .. und, aber dazu hatte ich keine Nerven mehr :roll:
Habe jedenfalls powersaved und hwscan deaktiviert. Wenn jetzt die Kiste mal 2 Wochen anstandslos durchläuft, wäre das wohl ein einmaliger Kernel Oops gewesen. @CC das war wirklich der ganze Oops, mehr stand da nicht drin, oder verstehe ich etwas falsch ? :oops:

Hier noch ein paar Daten der Kiste

Intel Pentium 4 CPU 2.80GHz
Memory 1GB
SuSE 9.3 Linux
Kernel 2.6.17.5-060712a
Plesk 8.0.1
Webmin 1.290
Qmail
Apache 2.0.53 mit mod_security und mod_evasive
rkhunter

2 Kunden mit (chrooted) shell access
41 Kunden
119 Domains

Hoffentlich/scheinbar hat sich dieses Problem erledigt und taucht niemals wieder auf.

Gruss, Danu

[captaincrunch]

@CC das war wirklich der ganze Oops, mehr stand da nicht drin, oder verstehe ich etwas falsch ?

Dann ist das der kürzeste Oops, den ich bisang zu Gesicht bekommen habe. Schau vielleicht noch mal nach.

[danu]

Ja ich hätte auch gerne mehr erfahren. Aber die Kiste war ja total weg und konnte keine Logs mehr schreiben. Dieser Oops stand im /var/log/messages ganz am Schluss und voran standen die üblichen Logs betreffend mail, logins, etc.
Ich habe mich jetzt mal dran gemacht, das ganze Loging besser und übersichtlicher zu organisieren. Ich habe mich jetzt lange genug genervt. Logs, die nicht so von Bedeutung sind füllen MB um MB und bei anderen Prozessen, über die ich auch gerne Bescheid wüsste, ist nichts drinn.

[danu]

Über die Hardware Info von Yast bin ich noch auf folgendes gestossen

<6>EXT3 FS on sda1, internal journal
<6>device-mapper: 4.6.0-ioctl (2006-02-17) initialised: dm-devel@redhat.com
<5>XFS mounting filesystem sda5
<7>Ending clean XFS mount for filesystem: sda5
<5>XFS mounting filesystem sda6
<7>Ending clean XFS mount for filesystem: sda6
<5>XFS mounting filesystem sda7
<7>Ending clean XFS mount for filesystem: sda7
<5>XFS mounting filesystem sda8
<7>Ending clean XFS mount for filesystem: sda8
<6>e100: eth0: e100_watchdog: link up, 100Mbps, full-duplex
<5>sd 0:0:0:0: Attached scsi generic sg0 type 0
<4>program dmraid is using a deprecated SCSI ioctl, please convert it to SG_IO
<4>program dmraid is using a deprecated SCSI ioctl, please convert it to SG_IO
<4>program dmraid is using a deprecated SCSI ioctl, please convert it to SG_IO
<4>program dmraid is using a deprecated SCSI ioctl, please convert it to SG_IO

.. die letzten 4 Zeilen wiederholen sich ca. 50 mal.

Gresecurity berichtete von einem möglichen (..?) Vorzeichenproblem in der generischen SCSI ioctl Behandlung. Übergrosse NFS Direct I/O Anfragen konnten zu einem lokalen DoS führten.

Habe mir mal die Linux SCSI Programmierung HOWTO runtergeladen.

Gruss, danu

[danu]

das wars dann wohl ...

Code: Select all

<6>Adding 2049016k swap on /dev/sda2.  Priority:-1 extents:1 across:2049016k
<6>EXT3 FS on sda1, internal journal
<6>device-mapper: 4.6.0-ioctl (2006-02-17) initialised: dm-devel@redhat.com
<5>XFS mounting filesystem sda5
<5>Starting XFS recovery on filesystem: sda5 (logdev: internal)
<5>Ending XFS recovery on filesystem: sda5 (logdev: internal)
<5>XFS mounting filesystem sda6
<5>Starting XFS recovery on filesystem: sda6 (logdev: internal)
<5>Ending XFS recovery on filesystem: sda6 (logdev: internal)
<5>XFS mounting filesystem sda7
<7>Ending clean XFS mount for filesystem: sda7
<5>XFS mounting filesystem sda8
<5>Starting XFS recovery on filesystem: sda8 (logdev: internal)
<1>Filesystem "sda8": xfs_inode_recover: Bad inode log record, rec ptr 0xc1912520, ino 235008721
<1>Filesystem "sda8": XFS internal error xlog_recover_do_inode_trans(2) at line 2362 of file fs/xfs/xfs_log_recover.c.  Caller 0xc022ae50
<4> <c022a86d> xlog_recover_do_inode_trans+0x93d/0xa00  <c022ae50> xlog_recover_do_trans+0x140/0x160
<4> <c02453ab> xfs_buf_delwri_queue+0x2b/0xb0  <c0240d7f> xfs_read_buf+0x3f/0x110
<4> <c0244793> xfs_buf_iostart+0xb3/0xc0  <c022ae50> xlog_recover_do_trans+0x140/0x160
<4> <c02411ff> kmem_zalloc+0x1f/0x50  <c022af4f> xlog_recover_commit_trans+0x3f/0x50
<4> <c022b06a> xlog_recover_process_data+0xea/0x240  <c022c51a> xlog_do_recovery_pass+0x82a/0xb70
<4> <c022c8f6> xlog_do_log_recovery+0x96/0xd0  <c022c96b> xlog_do_recover+0x3b/0x170
<4> <c022cb7d> xlog_recover+0xdd/0xf0  <c0223a71> xfs_log_mount+0xa1/0x110
<4> <c022e3ae> xfs_mountfs+0x7ee/0xf30  <c011a657> __wake_up_locked+0x27/0x30
<4> <c0266f5f> _atomic_dec_and_lock+0x3f/0x60  <c024bd0a> xfs_barrier_test+0x7a/0xa0
<4> <c021efe7> xfs_ioinit+0x27/0x50  <c0236fbf> xfs_mount+0x2ff/0x520
<4> <c024cc53> vfs_mount+0x43/0x50  <c024cc53> vfs_mount+0x43/0x50
<4> <c024ca6a> xfs_fs_fill_super+0x9a/0x200  <c026b1f7> snprintf+0x27/0x30
<4> <c01a33c4> disk_name+0x64/0xc0  <c016d46f> sb_set_blocksize+0x1f/0x50
<4> <c016ce76> get_sb_bdev+0x106/0x150  <c0175100> __link_path_walk+0xcf0/0xd50
<4> <c024cc00> xfs_fs_get_sb+0x30/0x40  <c024c9d0> xfs_fs_fill_super+0x0/0x200
<4> <c016d0cf> do_kern_mount+0x5f/0xe0  <c01846c7> do_new_mount+0x77/0xc0
<4> <c0184d1d> do_mount+0x18d/0x1f0  <c0184b33> copy_mount_options+0x63/0xc0
<4> <c01850cf> sys_mount+0x9f/0xe0  <c0102e6f> sysenter_past_esp+0x54/0x75
<4>XFS: log mount/recovery failed: error 990
<4>XFS: log mount failed
Kernel logging (ksyslog) stopped.
Kernel log daemon terminating.

:roll:

[danu]

Der Vollständigkeit halber hier noch die Lösung des Problems:

Nachdem der freundliche Support bei S&P mit "xfs_repair" die Partition wieder mountfähig gemacht hatte, bestand weiterhin eine Inkonsistenz derselben (des öfteren Dateizugriffsfehler, Kiste schmierte weiter im 2-Stundentakt ab). Auch ein mehrmaliger "fsck" änderte an diesem Zustand nichts.

Als letzte Lösungmöglichkeit setzte ich diese Partition neu auf, spielte die Daten zurück und startete die Kiste neu. Seither läufts wie geschmiert, als ob plötzlich ein zusätzlicher Prozessor am Laufen wäre.

Gruss, danu

[thorsten]

Wir hatten neulich die selben Probleme, als wir in der dom0 eines SATA Servers unter debian/sarge die smartmontools zur Überwachung der Platten installierten:
Die Maschine lief keine 24 Std durch.

Also flux die smartmontools runtergeschmissen und sämtliche domUs laufen wieder stabil.