TS-459 Pro II fährt selbstständig herunter.

    Hallo zusammen,
    seit 12.03.2013 fährt meine TS 459 Pro II ohne eine Konfigurationsänderung, ohne USV und ohne Zeitplan einfach irgendwann herunter und schaltet sich aus. Dies ist Heute bereits 2-3 mal passiert. Davor ist die NAS immer und zuletzt seit dem manuellen Restart am 26.01.2013 durchgängig gelaufen. Im Systemlog kann ich nichts erkennen Nachfolgend das Log seit dem 12.03.2013. Wo kann hier der Fehler liegen?


    Danke und Gruß,


    swrue

    Einmal editiert, zuletzt von bladekiller () aus folgendem Grund: Code Block hinzugefügt, siehe Forenregeln!

    Hallo,
    Aus den Protokollen kann ich leider den Uebeltaeter nicht auslesen.
    Was hast du denn alles auf deinem NAS laufen?
    Ich habe nur mal das gegenteilige Problem gelesen, wo das NAS manchmal mitten in der Nacht gestartet ist.
    Hast du vlt. ein QKPG drauf, welches irgendwofuer einen Neustart braucht und deshalb das NAS herunterfaehrt?

    Hallo zusammen,
    ich habe ein Ticket bei QNAP eröffnet und folgendes erhalten:


    Die bisherige Fehlerbeschreibung/Fehleranalyse Ihres QNAP NAS deutet auf eine Fehlkonfiguration im Betriebsystems Ihres QNAP NAS hin.
    Womöglich hilft nur ein "Hardware Reset" um das beschriebene Verhalten zu korrigieren.


    Der "Hardware Reset" kann in zwei Varianten angewendet werden:
    Variante 1 ist die meist erfolgreichere Methode, allerdings müssten vorher Ihre Daten gesichert werden.
    Bei Variante 1 werden die Festplatten formatiert, da sich hier große Teile des QNAP NAS Betriebssystems befinden.


    Bitte schließen Sie Ihr NAS direkt an einen PC oder Laptop, über ein LAN-Kabel, an.


    Der "Hardware Reset" kann in zwei Varianten angewendet werden:


    1.) TOTALER URZUSTAND mit FESTPLATTEN Formatierung (also vorher Daten sichern).
    Bitte folgende Schritte ausführen:
    Systemeinstellungen notieren - diese müssen nach dem Hardwarereset neu eingegeben werden. Sie werden aufgefordert die Festplatten zu formatieren.
    Bitte zunächst alle Dienste auf dem NAS, temporär und um mögliche Fehlerquellen einzugrenzen, abschalten (falls möglich).
    Dann bitte NAS OHNE(!) Festplatten starten.
    Nach einem Kurzen Biep-Ton gefolgt von einem langem Biep-Ton (ca. 2 Minuten nach dem kurzen Biep-Ton) die Festplatten wieder einschieben (Hot-Plug).
    Jetzt QNAP Finder oder Quick Install Wizard starten - das NAS sollte gefunden werden und kann jetzt über diese Software konfiguriert werden.
    Bitte den entsprechenden Anweisungen des Assistenten folgen. Bei der Frage nach Festplatte initialisieren oder formatieren bitte mit "Ja" bestätigen.
    Nach der Installation Ihres NAS / Ihres NAS-Betriebssystems alle notwendigen Dienste/Services wieder zuschalten.


    Wenn Sie SSH Zugang haben (Linux-Kenntnisse erforderlich), lassen sich noch einige hilfreiche Auswertungen machen.
    Hierzu mit SSH über die Linux Konsole in Verzeichnis /var/log wechseln. Hier finden Sie weitere Warnmeldungen mit "vi LOGFILENAME"
    anschauen (:q zum Beenden des Editors). oder mit "dmesg |more"
    auslesen. Evtl. zunächst mit dmesg -c alte Einträge löschen, dann neu starten und dmesg zum auslesen verwenden.
    Mit Befehl "ps" die aktuelle Prozessliste auslesen. z.B. ps > ausgabe.ps.txt (vorher: cd /share/Public)
    Mit "top" aktuell laufende Programme zeigen. z.B. top > ausgabe.top.txt (mit q oder Ctrl C beenden) und:
    # cd /share/Public
    # touch kmsg.txt
    # cat /proc/kmsg > ausgabe.kmsg.txt
    und:
    # dmesg


    2.) "Hardware Reset" OHNE DATENVERLUST aber Systemeinstellungen werden zurückgesetzt:
    Bitte folgende Schritte ausführen für den Hardware Reset (Sie sollten über LINUX Kenntnisse verfügen, oder einen entsprechenden Administrator hinzuholen):
    Systemeinstellungen notieren - diese müssen nach dem Hardwarereset neu eingegeben werden.
    Bitte zunächst alle Dienste auf dem NAS, temporär und um mögliche Fehlerquellen einzugrenzen, abschalten (falls möglich).
    Dann bitte NAS ohne Festplatten starten.
    Nach einem Kurzen Biep-Ton gefolgt von einem langem Biep-Ton (ca. 2 Minuten nach dem kurzen Biep-Ton) die Festplatten wieder einschieben (Hot-Plug).
    Jetzt QNAP Finder oder Quick Install Wizard starten - das NAS sollte gefunden werden. (bitte neueste QNAP Finder Software verwenden - Download auf http://www.qnap.de)
    Ihr NAS nur über QFinder konfigurieren wenn keine Daten gesichert werden müssen - Sie werden zum formatieren der Festplatten aufgefordert.
    Wenn Ihre Daten gerettet werden sollen folgende Schritte ausführen:
    Zum NAS über Telnet port 13131 oder SSH verbinden (QFinder zeigt Ihnen die IP-Adresse)
    Folgende Befehle ausführen (Bei RAID Verbund)
    # mdadm -A /dev/md9 /dev/sda1 /dev/sdb1 /dev/sdc1 /dev/sdd1 (in
    Abhängigkeit davon, wie viele Platten Sie verwenden)
    # mount /dev/md9 /mnt
    # cd /mnt/.config/
    # cp /etc/default_config/uLinux.conf /mnt/.config/
    # reboot


    Ihr NAS ist jetzt unter der obigen IP-Adresse mit Default-Systemeinstellungen erreichbar.
    Jetzt alle notwendigen Dienste wieder zuschalten.



    Leider hat Methode 2 nicht zum Erfolg geführt und die NAS fährt noch immer selbstständig herunter.
    Nun werde ich Methode 1 probieren und auf Erfolg hoffen.


    Gruß,


    swrue



    ---Edit---



    Hallo zusammen,


    ich habe nun mit Methode 1 pobiert und die NAS komplett neu in Betrieb genommen. Dies ging 3,5h gut und dann ist sie noch während des Daten-Restore wieder selbstständig heruntergefahren. Also ein Reopen im QNAP Ticket und bis Montag warten. :cursing:


    cu,
    swrue

    Einmal editiert, zuletzt von bladekiller () aus folgendem Grund: Editierfunktion nutzen und doppelte Beiträge vermeiden, siehe Forenregeln!

    Hallo,
    Ich haette eine Variation der ersten Methode vorzuschlagen.
    Daten und Einstellungen sichern, NAS ohne Platten starten und Reset durchfuehren.
    Platten an den PC anschliessen und alle Volumen/Partitionen loeschen.
    Unter Win7 geht das so: Systemsteuerung > Verwaltung > Computerverwaltung > Datenspeicher > Datenträgerverwaltung
    Dabei gehen alle Daten verloren :!:
    Platten wieder einbauen und NAS starten.
    Anschliessend am besten alles von Hand wieder einstellen und Daten einspielen.

    Hi,
    für Deine Variation der Methode 1 muss ich mir erstmal ein passendes externes Gehäuse besorgen, da ich keinen Desktop zur Verfügung habe.


    Dem Support hatte ich ja bereits mitgeteilt beim Reopen des Tickets, dass ich Methode 1 bereits erfolglos durchgeführt hatte. Dieser teilte mir mit, ich solle Methode 1 durchführen (die ich bereits durchgeführt hatte) und haben das Ticket wieder geschlossen. Dann hab ich wieder ein Reopen des Tickets gemacht und noch mal klargestellt, dass ich Methode 1 durchgeführt habe, aber das Problem weiterhin besteht. Antwort war, so was könne nicht sein und ich solle Methode 1 durchführen und das Ticket wurde wieder geschlossen. Heute habe ich wieder Methode 1 durchgeführt (komplette Neuinstallation mit HDD Formatierung und neu einstellen sämtlicher Settings, Shares usw.) Installationsstart 11:41h selbstständiger shutdown um 20:14h !!!!
    Also habe ich wieder mal ein Reopen des Ticket durchgeführt.


    Es ärgert mich richtig wie der Support so etwas einfach schließt und meint es müsse damit erledigt sein. Ja es gibt DAU's auf dieser Welt, aber es muss nicht jeder einer sein und ich kann Support Anweisungen folgen (zumal es einfach ist). :cursing:


    Hat jemand eine Idee woran es hängen kann, wenn der Support bisher nicht in der Lage ist auf das Problem richtig einzugehen?
    Andernfalls muss ich mir das passende externe USB Gehäuse besorgen und dem Vorschlag von TobiasK folgen und die Variation von Methode 1 probieren.


    Danke und Gruß,


    swrue

    Hi, deine Verärgerung über den Support, kann ich voll und ganz verstehen.
    Jetzt müssen wir aber hier erstmal sehen, wie wir die Kuh vom Eis bekommen.
    Ohne ein Vollbackup, brauchen wir nicht anfangen zu überlegen.

    Zitat von "frosch2"

    Ohne ein Vollbackup, brauchen wir nicht anfangen zu überlegen.


    Wofür ein Vollbackup, wenn...

    Zitat von "swrue"

    Heute habe ich wieder Methode 1 durchgeführt (komplette Neuinstallation mit HDD Formatierung und neu einstellen sämtlicher Settings, Shares usw.)

    :?:


    @TE
    Kopiere die /etc/logs/kmsg.2 vom NAS und hänge diese mal hier als Dateianhang an.
    Wenn es diese nicht gibt, dann die /etc/logs/kmsg.1

    Zitat von "dr_mike"

    Wofür ein Vollbackup, wenn...

    :?:


    Stimmt, ist eh zu spät.

    Den Protokollen ist nichts zu entnehmen, was auffällig wäre. Das System scheint regulär heruntergefahren zu werden.
    Poste bitte mal die Ausgabe von

    Code
    cat /proc/driver/rtc

    Hallo Mike,


    genau das ist mein Problem. Nachfolgend die Ausgabe von cat /proc/driver/rtc



    Gruß,
    swrue

    Einmal editiert, zuletzt von GorillaBD () aus folgendem Grund: Code Block hinzugefügt.

    Auch da ist erstmal nichts auffälliges zu sehen. CMOS-Battery ist ok.
    Poste mal bitte die Ausgabe von

    Code
    cat /var/run/cron/crontabs/admin

    Hier nun die Ausgabe von cat /var/run/cron/crontabs/admin :


    Code
    # m h dom m dow cmd
0 3 * * 0 /etc/init.d/idmap.sh dump
0 4 * * * /sbin/hwclock -s
0 3 * * * /sbin/vs_refresh
0 3 * * * /sbin/clean_reset_pwd
0-59/15 * * * * /etc/init.d/nss2_dusg.sh
0 3 * * * /bin/rm -rf /mnt/HDA_ROOT/twonkymedia/twonkymedia.db/cache/*
0 3 * * * /etc/init.d/ImRd.sh bgThGen
4 3 * * 3 /etc/init.d/backup_conf.sh
5 13 * * *  /share/MD0_DATA/.qpkg/Squid/opt/sbin/squid -k rotate -f /share/MD0_DATA/.qpkg/Squid/opt/etc/squid/squid.conf


    Danke für Deinen Einsatz.


    Gruß,
    swrue

    Auch da ist nichts drin, was Anlass zur Besorgnis gäbe.
    Du könntest jetzt noch versuchen den squid mal zu deaktivieren und zu schauen obs dann nicht mehr auftritt.
    Desweiteren eventuell mal einen Monitor und Tastatur anschliessen und schauen, ob da irgendwelche Meldungen ausgegeben werden. Wobei du dann natürlich davorsitzen müsstest wenns auftritt. Dürfte beinahe unmöglich sein. :mrgreen:


    Weitere Möglichkeit wäre, die entsprechenden Initscripte zu modifizieren, dass sie eine Meldung mit Zeitstempel in eine Datei auf der Platte schreiben, um herauszufinden, von wo aus der Aufruf kam. Das ist allerdings etwas aufwändiger und die Änderungen sind nach dem Neustart wieder weg.

    Ok, ich habe den Squid deaktiviert und werde abwarten und beobachten.


    Den Zeitpunkt des shutdown mitzubekommen ist absoluter Zufall und wird nicht funktionieren.


    Ich finde Dein Vorschlag gut die entsprechenden Init Scripte zu modifizieren, damit eine Meldung mit Zeitstempel in eine Datei auf der Platte geschrieben wird, um herauszufinden, von wo aus der Aufruf kam. Wenn ich wüsste was und wo die Modifikationen gemacht werden müssen, würde ich es machen. Auch wenn die Änderungen nach dem Neustart wieder weg sind, geben die Meldungen hoffentlich Hinweise. Kannst Du mir die Modifikationen nennen?


    Danke und Gruß,
    swrue

    Die Modifikation könnte sowas sein wie

    Code
    CURTIME="/bin/date +%Y-%m-%d_%H.%M.%S"
LOGFILE="/share/Public/shutdown.log"
/bin/echo "["`${CURTIME}`"]: $*" >> "$LOGFILE"
/bin/sync


    Somit würde die aktuelle Zeit und der komplette Aufruf des entsprechenden Scripts in die Datei shutdown.log geschrieben werden. Platzieren würde ich das relativ weit oben im Script, sodass es auf jeden Fall durchlaufen wird, bevor irgendeine exit-Bedingung greift.

    Wird dabei abgefragt was den shutdown initiiert? Der erste Teil definiert ja die Variablen und dann soll die Zeit ins Logfile geschrieben werden.
    Wird durch das /bin/sync abgefragt was den shutdown initiiert?
    Und die nächste Frage ist, in welches Script das eingefügt werden muss?


    Danke Dir und Gruß,


    swrue

    Zitat von "swrue"

    Wird dabei abgefragt was den shutdown initiiert?


    Nein, es wird damit nur geloggt, ob und wie das Script aufgerufen wurde. /bin/sync sagt nur, dass der Cache sofort auf die Platte geschrieben werden soll.

    Zitat von "swrue"

    in welches Script das eingefügt werden muss?


    Am Besten in alle - nein, Scherz beiseite. :mrgreen: Ich würde es erstmal überall dort eintragen, wo ein Poweroff ausgelöst werden kann.

    Code
    /etc/apcupsd/apccontrol
/etc/init.d/update_img.sh
/etc/init.d/usb_ups.sh
/etc/init.d/power_button.sh
/etc/init.d/poweroff
/etc/init.d/genpowerfail.sh


    Desweiteren solltest du mal die Systemverbindungsprotokolle aktivieren, um zu schauen, ob sich da jemand anderes mit Adminrechten rumtummelt.

    Ich habe nun die benannten Scripte um die Einträge erweitert. Dann warte ich mal auf den nächsten shutdown.


    --- EDIT ---


    Und schon ist wieder ein shutdown aufgetaucht, aber mit nur den nachfolgenden Einträgen im Log:

    Code
    [2013-03-24_12.18.48]:
[2013-03-24_12.19.22]: stop


    Das ist nicht wirklich hilfreich, oder? Kann noch etwas ergänzt werden in den Scripts, damit mehr Infos ins log geschrieben werden?


    Danke und Gruß,
    swrue

    Einmal editiert, zuletzt von GorillaBD () aus folgendem Grund: Doppelte Beiträge vermeiden, siehe Forenregeln!

    Zitat von "swrue"

    Das ist nicht wirklich hilfreich, oder?


    Da hast wohl recht. Ist aber mein Fehler. Da fehlte noch was.
    Die Zeile

    Code
    /bin/echo "["`${CURTIME}`"]: $*" >> "$LOGFILE"


    muss natürlich richtigerweise lauten

    Code
    /bin/echo "["`${CURTIME}`"]: $0 $*" >> "$LOGFILE"