TS-559: Seit 3.5.1.x kein Zeitstart am Sonntag mehr

    Hallo --


    ich habe 2 QNAP, 1 x TS-559 Pro und 1 x TS-559 Pro+ Beide laufen zeit-gesteuert (da in der Nacht kein Betrieb notwendig/nicht sinnvoll). Einer hat unterschiedliche Zeiten für Wochentag, Samstag, Sonntag. Der andere verwaltet mit RSnapshot täglich ein Archiv und läuft von 17:15 Uhr bis 20:30 Uhr.


    Die entsprechenden Zeiten sind in der "Energieverwaltung" eingestellt. Seit Upgrade auf 3.5.1.x laufen beide QNAP nicht mehr am Sonntag an - muss dann per Tastendruck oder WOL starten. Der Fehler muss mit der 3.5.0 entstanden sein (Downgrade bringt keine Lösung). Mit 3.4 ist alles korrekt gelaufen.


    Die Dateien mit den Daten zur Zeitsteuerung sehen gut aus (in der Crontab steht ja immer nur der "nächste" Tag, die gesamte Definition ist separat abgelegt). Die Crontab müßte ich noch am nächsten Samstag nach dem Systemstart prüfen - leider gestern übersehen.


    Kennt jemand dieses Problem? Wo wäre ein guter Ansatz nach der Ursache zu forschen? Wie gesagt, beide haben unterschiedliche EInstellungen, der zweite QNAP sogar "täglich", also noch einfacher geht's nicht. Aber beide wollen am Sonntag weiter schlafen :mrgreen:


    Danke -- Klaus

    Hi,


    hab den selben Fehler, aber erst seit der neusten 3.5.1


    QNAP SUpport gibt hier auch keine Hilfe, akzeptieren den Fehler nicht.. Sollst Dein System platt machen und neu aufspielen usw.. :cursing:


    Ich lebe mit den Fehler derzeit... und hoffe das beim nächsten Update der raus ist..


    p.s. kannst gerne den Fehler nochmal an QNAP melden vielleicht bringt das ja was...


    Tomas

    Ich habe den Fehler auch seit der 3.5.1 - allerdings musste ich mit der Rettungs CD das ganze System neu aufsetzen, da das Update nicht funktionierte.
    (Nach dem Wiederherstellen und dem anschließenden Update auf die aktuelle Firmware waren allerdings alle Daten und Einstellungen wieder da, also kein wirklich komplettes Neuaufsetzen.)


    Mir ist heute erst aufgefallen, dass das System gar nicht erst runtergefahren ist, da es heute früh noch an war.


    Habe die Zeitsteuerung einmal deaktiviert und wieder aktiviert, mal schauen, ob das etwas bringt.

    Danke für beide Antworten. Ich analysiere das weiter. Ein-/Ausschalten der Zeitsteuerung bringt nichts, das hatte ich schon versucht.


    Der nächste Schritt ist eine Kontrolle der Crontab, und zwar am Freitag nach dem Systemstart. Die Systeme speichern die Zeitsteuerung in /MNT/HDA_ROOT/Config/schedult_boot_setting. Dann wird, nach jedem Start bzw. beim Runterfahren, in die Crontab der Start-/Stopp für den nächsten Start/Stopp geschrieben. Es steht dann die Nummer des Tages drin: 1 = Montag .... 6 = Samstag und 7 sollte Sonntag sein. Ich vermute dass hier die falsche Tagesnummer eingetragen wird, vielleicht im Zusammenhang mit dem Sonntag als letzten Tag der Woche (wie bei uns) oder erstem Tag der Woche (in anderen Regionen der Welt). Oder die Kalender-Kalkulation ist durch einen Update defekt.


    Ich beobachte das weiter und hänge die Beobachtungen dann übernächste Woche an (muß bis Samstag/Sonntag warten, nur dann haben wir gesicherte Erkenntnisse).


    Wenn ich dann lese "QNAP akzeptiert den Fehler nicht" ... scheint so dass bei QNAP die Software-Entwicklung so langsam außer Kontrolle gerät. Qualitätssicherung und Regressionstests kennen die offensichtlich nicht. Ein Bug wie dieser kommt nicht durch Zufall, da ist an bestimmten Funktionen gearbeitet worden - und dann gehört das auch verifiziert. Da fehlt's an grundsätzlichen Prozeduren.


    -- Klaus

    Hi,


    ich schätze es passiert in Jedem Falle jeden Sonntag, bei mir nun zum 3x (Immer Sonntag)..


    So und nun kommts....

    Ich habe mal Heute die Crontab ausgelesen und da steht :


    15 1 * * 6 /etc/init.d/poweroff


    die 6 steht für den Wochentag Samstag !! Und wir haben Sonntag, meine Jobs sind aber Täglich !
    Also das nenne ich mal einen Fehler.. Da müsste die 1 für morgen stehen !!


    De/Aktiviere ich nun den Zeitplan (also einmal ausschalten in der GUI und dann wieder einschalten) dann korrigiert er auch den Eintrag auf:


    15 1 * * 1 /etc/init.d/poweroff


    :arrow:
    Das ist doch sehr merkwürdig !
    :arrow:


    Wenn Du die QNAP nun manuell durchgestartet hast dann korrigiert er das natürlich und du siehst diesen fehlerhaften Eintrag nicht mehr.


    Damit würde die QNAP mehrere Tage durchlaufen.. ohne einmal runterzufahren.. Da scheint entweder ein Dienst zu hängen oder einfach nix mehr zu machen...
    Da ich mein NAS aber jeden Tag herunterfahre kann das kein Problem sein das sich aufschaukelt, der CRON / Shutdown wird dann am Samstag einfach nicht geändert und bleibt auf dem alten Eintrag stehen..


    ..


    Mit den Support sehe ich das etwas gemäsigter, da rufen denke ich auch viele NOOBS an, und die Schützen sich einfach mit ihren Standardemails etc... Sind denke ich auch zu wenige... Heute ist es ja leider überall, mit den Kostensparen auf Teufel komm raus..


    Vielleicht helfen die ja jetzt und melden den Defect zu den Programmierern.. Ich hoffe das mal... Der Fehler ist aber auch schon Schei..eeeee. :cursing:


    Tomas

    Hallo zusammen,
    meine TS-419P (3.3.1 Build 0720T) soll sich auch abends aus und morgens einschalten.
    Dieses habe ich so über die "Energieverwaltung - Einschalten/Ausschalten/Neustart-Plan festlegen" mit "täglich um..." auch eingestellt.
    Soweit so gut ... im Allgemeinen funktioniert es.


    Nur wie auch hier beschrieben kommt es vor, dass die Crontabeinträge nicht richtig eingestellt werden. Oft ist dieses zum Sonntag so. Es kann auch vorkommen, wie heute am Montag, dass die Crontab wächst.
    0 23 * * 0 /etc/init.d/poweroff
    0 23 * * 1 /etc/init.d/poweroff
    0 6 * * /etc/init.d/startup


    Weiß jemand, welcher Prozess / welches Script die Einstellung an der Crontab vornimmt?

    Bitte !!!
    Weiß jemand, welcher Prozess / welches Script die Einstellung für Ein/Ausschalten an der Crontab vornimmt?

    Jetzt habe ich das mal eine Woche lang überwacht. Ergebnis:


    Am Freitag wird in die Crontab (für Start am "nächsten" Tag) die 6 (= Samstag) reingeschrieben.
    Am Samstag dann die "1" (= Montag). Der Sonntag wird damit übersprungen (ausgelassen).


    Habe die beiden System dann am Sonntag manuell gestarted.


    Am Sonntag steht in der Crontab jetzt zum nächsten Ausschalten (also heute, Sonntag abend) eine "0".
    Zum nächsten einschalten steht die "1" drin.


    Bei QNAP beginnt die Woche also am Sonntag ("0") und geht bis Samstag ("6").
    Geschrieben werden aber nur die Werte "1" bis "6". :shock:


    Ich werde mal eine freundliche Mail an den Support schicken.


    Gruß, Klaus

    Hallo,


    ich habe seit dem update das gleiche problem. Liegt wohl eindeutig an der neuen FW.


    Jetzt muss ich allerdings nochmal blöd nachfragen: wie kann ich die Crontab auslesen???


    Besten Dank

    Hi,
    in der shell einfach:
    crontab -l


    Wenn Du die Zeitsteuerung aus/an machst sollte sich der falsche Eintrag der ggf. am Samstag generiert wird wieder korrigieren.. Falls das nicht schon
    ein Neustart der QNAP erledigt haben sollte. Dann ändert sich auch gleich die crontab ;)


    Warten wir mal auf die Gefixte BUGLISTE der nächsten FW Version...


    Bis dahin mache ich Samstags einen manuellen SHUTDOWN..


    Tomas

    Einmal editiert, zuletzt von christian () aus folgendem Grund: Volltextzitat entfernt!

    Ich kann den Fehler ebenfalls bestätigen.


    Ich habe die neue Firmware 3.5.1 erst letzte Woche aufgespielt und seit Sonntag fährt sich der TS-419P nicht mehr automatisch runter. Ich hatte erst auf Probleme mit der am Wochenende erfolgten Sommer-/Winterzeitumstellung getippt. Den Server habe ich jetzt erst mal manuell gestoppt und wieder gestartet. Jetzt schaue ich mal, ob er sich heute Abend wieder von selbst runterfährt.

    Hi,
    habe das Problem auch, 239 Pro II faehrt seit dem letzten Update nicht mehr automatisch runter.
    Werde es an QNAP melden....
    Das ist eindeutig ein BUG!
    Gruesse,
    Christian!

    Ich schließe mich auch an mit meinem 212... immer wieder sonntags...
    Zieht sich anscheinen durch die letzte 3.5.1-Firmware - egal welches Modell.

    Hi,


    wir müssen da wohl auf das nexte FW Update warten... ich hoffe das ist halbwegs fehlerfrei...
    Bis dahin lebt damit...


    p.s. wenn Ihr den Zeitscheduler einfach einmal aus / einschaltet dann geht es wieder... (bis zum nexten sonntag...)..


    Kann man in der CRON sehen... da Fehlen dann einfach die Einträge für den Sonntag.


    Evtl sind einfach auch zu viele Mülldaten in der Datei "/etc/config/schedule_boot_settings" hier werden die Einträge aus der GUI nämlich abgelegt.. Den Inhalt kann man komplett löschen und dann in der GUI alles neu Konfiguieren..


    Tomas

    Das Problem besteht wahrscheinlich schon seit 3.5.0. Ich habe 4 Qnaps. 2 haben Fehler in der Zeitsteuerung.
    Normalerweise werden alle täglich um 7 Uhr gestartet und um 20 Uhr ausgeschaltet.


    (1) TS-219 3.5.1 startet nicht am Sonntag.
    (2) TS-219 3.5.0 funktioniert problemlos.
    (3) TS-239 Pro II 3.5.0 seit 9.11.11 (Mittwoch) nicht mehr heruntergefahren.
    (4) TS-412 3.5.0 funktioniert problemlos.

    Mein 439 Pro II wird seit seiner Inbetriebnahme in 2010 jede Nacht um 01:00 per Scheduler aus- und um 06:00 Uhr wieder eingeschaltet.


    Das hat bis einschliesslich 3.5.0 einwandfrei funktioniert. Erst nach Einspielen von 3.5.1 fährt es Sonntags um 01:00 Uhr nicht mehr runter.


    Es handelt sich somit m.E. ganz klar um einen 3.5.1er Bug.


    De-/Reaktivieren des Schedules reicht nicht aus. Es ist ein Neustart des NAS erforderlich.


    Viele Grüße


    Thomas

    Bei mir existiert der Bug (das das Gerät Sonntags nicht von alleine startet) seit dem Upgrade auf die Version 3.5.1.


    Bis einschliesslich Version 3.5.0 gab es mit der Zeitsteuerung bei mir keine Probleme.


    Das Herunterfahren übernimmt das Script "wait4Pc" deswegen funktioniert das auch mit Version 3.5.1.

    [youtube]

    Externer Inhalt www.youtube.com
    Inhalte von externen Seiten werden ohne Ihre Zustimmung nicht automatisch geladen und angezeigt.
    Durch die Aktivierung der externen Inhalte erklären Sie sich damit einverstanden, dass personenbezogene Daten an Drittplattformen übermittelt werden. Mehr Informationen dazu haben wir in unserer Datenschutzerklärung zur Verfügung gestellt.
    [/youtube]


    :mrgreen:


    bug ist in firmware 3.5.2 gefixt, erscheint sehr bald.

    Ich habe die FW 3.5.2 installiert und das Sonntagsproblem ist heute nicht mehr aufgetreten. Bevor ich ein Produktivsystem von FW 3.4.x auf 3.5.x upgrade meine Frage: Ist bei Euch der Sonntagsfehler nach dem Upgrade auf FW 3.5.2 auch verschwunden?


    Schönen Sonntag noch
    TBWS