GuaRdiaN
Captain
- Registriert
- Mai 2001
- Beiträge
- 3.214
Hi Leute,
heute habe ich einen kuriosen Fehler in meinem Server entdeckt. Dabei scheint nach einiger Recherche bei Google der Schuldige die Festplatte zu sein. Allerdings habe ich nach einiger Zeit herausgefunden, dass das mit der Platte an für sich nichts zu tun hat:
Euer Server liefert im dmesg:
Sucht man danach stellt man recht schnell fest, dass es sich offenbar um ein Kommando handeln muss, dass an den Controller (und die daran angeschlossene Festplatte) gesendet wird, offenbar aber nicht verstanden wird.
Also die These von wegen HDD vorerst über Board geworfen, damit man offen für weiteres Bleibt. Dann habe ich mir die Datei /etc/default/smartmontools angesehen:
Per default wird also ein SCAN aller im System befindlichen Laufwerke vorgenommen, also habe ich mir gedacht, das könnte das Problem sein, also habe ich ein paar Zeilen Weiter den Eintrag geändert:
Nach einem Neustart des Moduls ändert sich aber nichts. Scheint also nicht von dem Dienst direkt auszugehen, also habe ich mir das Intervall angesehen, in dem diese Einträge gemacht wurden. Dabei stellte sich heraus, dass die Einträge in einem konstanten Intervall auftreten.
Anschließend war klar, dass es eine logging / statistik Instanz auf dem System ein muss. Also ein wenig durch die dpkg -l gestöbert, und dann war es eigentlich klar:
MUNIN!!
Ein Blick in /var/log/syslog gab dann die Bestätigung:
Also zusammenfassend: Es hat nichts mit den Festplatten zu tun, offenbar ist der Treiber des 3Ware Controllers nicht im Stande den Befehl durch smartmontools zu verarbeiten. Im Internet existiert ein Tutorial von LSI, welches beschreibt wie sich der Fehler angeblich fixen lässt, allerdings habe ich meine Maschine hier im Haus im Produktiveinsatz, sodass ich kein schnellen Reboot machen kann. Falls ich es testen sollte, werde ich berichten.
Der Link zur LSI Seite
Sollte jemand da weiterführende Informationen haben, please share it with us!
heute habe ich einen kuriosen Fehler in meinem Server entdeckt. Dabei scheint nach einiger Recherche bei Google der Schuldige die Festplatte zu sein. Allerdings habe ich nach einiger Zeit herausgefunden, dass das mit der Platte an für sich nichts zu tun hat:
Euer Server liefert im dmesg:
Code:
[ 3407.998025] 3w-9xxx: scsi0: ERROR: (0x03:0x0101): Invalid command opcode:opcode=0x85.
[ 3407.998463] 3w-9xxx: scsi0: ERROR: (0x03:0x0101): Invalid command opcode:opcode=0x85.
[ 3706.000060] 3w-9xxx: scsi0: ERROR: (0x03:0x0101): Invalid command opcode:opcode=0x85.
[ 3706.000430] 3w-9xxx: scsi0: ERROR: (0x03:0x0101): Invalid command opcode:opcode=0x85.
[ 4003.683287] 3w-9xxx: scsi0: ERROR: (0x03:0x0101): Invalid command opcode:opcode=0x85.
[ 4003.683678] 3w-9xxx: scsi0: ERROR: (0x03:0x0101): Invalid command opcode:opcode=0x85.
[ 4303.424833] 3w-9xxx: scsi0: ERROR: (0x03:0x0101): Invalid command opcode:opcode=0x85.
[ 4303.425225] 3w-9xxx: scsi0: ERROR: (0x03:0x0101): Invalid command opcode:opcode=0x85.Sucht man danach stellt man recht schnell fest, dass es sich offenbar um ein Kommando handeln muss, dass an den Controller (und die daran angeschlossene Festplatte) gesendet wird, offenbar aber nicht verstanden wird.
Also die These von wegen HDD vorerst über Board geworfen, damit man offen für weiteres Bleibt. Dann habe ich mir die Datei /etc/default/smartmontools angesehen:
Code:
# The word DEVICESCAN will cause any remaining lines in this
# configuration file to be ignored: it tells smartd to scan for all
# ATA and SCSI devices. DEVICESCAN may be followed by any of the
# Directives listed below, which will be applied to all devices that
# are found. Most users should comment out DEVICESCAN and explicitly
# list the devices that they wish to monitor.
DEVICESCAN -d removable -n standby -m root -M exec /usr/share/smartmontools/smartd-runnerPer default wird also ein SCAN aller im System befindlichen Laufwerke vorgenommen, also habe ich mir gedacht, das könnte das Problem sein, also habe ich ein paar Zeilen Weiter den Eintrag geändert:
Code:
# First two SCSI disks. This will monitor everything that smartd can
# monitor. Start extended self-tests Wednesdays between 6-7pm and
# Sundays between 1-2 am
/dev/sda -d scsi
#/dev/sdb -d scsi -s L/../../7/01Nach einem Neustart des Moduls ändert sich aber nichts. Scheint also nicht von dem Dienst direkt auszugehen, also habe ich mir das Intervall angesehen, in dem diese Einträge gemacht wurden. Dabei stellte sich heraus, dass die Einträge in einem konstanten Intervall auftreten.
Anschließend war klar, dass es eine logging / statistik Instanz auf dem System ein muss. Also ein wenig durch die dpkg -l gestöbert, und dann war es eigentlich klar:
MUNIN!!
Ein Blick in /var/log/syslog gab dann die Bestätigung:
Code:
Oct 25 16:45:01 server /USR/SBIN/CRON[14472]: (root) CMD (if [ -x /etc/munin/plugins/apt_all ]; then /etc/munin/plugins/apt_all update 7200 12 >/dev/null; elif [ -x /etc/munin/plugins/apt ]; then /etc/munin/plugins/apt update 7200 12 >/dev/null; fi)
Oct 25 16:45:01 server /USR/SBIN/CRON[14473]: (munin) CMD (if [ -x /usr/bin/munin-cron ]; then /usr/bin/munin-cron; fi)
Oct 25 16:45:04 server kernel: [ 4903.309546] 3w-9xxx: scsi0: ERROR: (0x03:0x0101): Invalid command opcode:opcode=0x85.
Oct 25 16:45:04 server kernel: [ 4903.309986] 3w-9xxx: scsi0: ERROR: (0x03:0x0101): Invalid command opcode:opcode=0x85.Also zusammenfassend: Es hat nichts mit den Festplatten zu tun, offenbar ist der Treiber des 3Ware Controllers nicht im Stande den Befehl durch smartmontools zu verarbeiten. Im Internet existiert ein Tutorial von LSI, welches beschreibt wie sich der Fehler angeblich fixen lässt, allerdings habe ich meine Maschine hier im Haus im Produktiveinsatz, sodass ich kein schnellen Reboot machen kann. Falls ich es testen sollte, werde ich berichten.
Der Link zur LSI Seite
Sollte jemand da weiterführende Informationen haben, please share it with us!
