Seite 2 von 2 ErsteErste 12
Ergebnis 11 bis 20 von 20
  1. #11
    Anwender
    Registriert seit
    26.08.2015
    Beiträge
    47

    Standard

    Kann mir einer kurz weiterhelfen und sagen, wie ich die Log zu "Ruhezustand-Debugging-Modus" herunterladen kann?

    Danke und Gruß,
    dia

    DS918+ (DSM 6.1.5-15254)
    DS214se (Off-Site)

  2. #12
    Anwender
    Registriert seit
    26.08.2015
    Beiträge
    47

    Standard

    Habs gefunden, SSH Zugang, Putty, Login, cp der Daten (/var/log/hibernation.log) in ein Verzeichnis, auf das ich auch normal zugriff habe.

    DS918+ (DSM 6.1.5-15254)
    DS214se (Off-Site)

  3. #13
    Anwender
    Registriert seit
    20.08.2016
    Beiträge
    12

    Standard

    cp geht auch.
    Zwei Möglichkeiten die ich gemacht habe um das Hibernation.log auszulesen:
    1.
    DSM Hauptmenü -> Support-Center -> Support-Dienste -> Protokollerstellung Haken bei System -> Button Protokolle erstellen
    Die debug.dat-Datei mit 7-zip entpacken, dann die /var/log/hibernation.log mit notepad++ öffnen.
    2. DSM Hauptmenü -> Terminal &SNMP -> Terminal -> SSH-Dienst aktivieren, Putty, Login mit Adminuser, root mit
    Code:
    sudo -i
    , admin passwort,
    Code:
    cat /var/log/hibernation.log
    bzw.
    Code:
    cat /var/log/hibernationFull.log
    Bei mir hat es mehr gebracht die crontab anzuschauen:
    Code:
    cat /etc/crontab  
    
    MAILTO=""
    PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/syno/sbin:/usr/syno/bin:/usr/local/sbin:/usr/local/bin
    #minute hour    mday    month   wday    who     command
    0       0       1       *       *       root    /usr/syno/bin/syno_disk_health_record
    0       2       *       *       5       root    /tmp/synoschedtask --run id=4
    0       2       *       *       5       root    /tmp/synoschedtask --run id=5
    0       2       *       *       5       root    /tmp/synoschedtask --run id=1
    und die synoschedtask zu prüfen
    Code:
    /tmp/synoschedtask --get id=1
                   ID: [1]
                 Name: [Speichernutzung]
                State: [enabled]
                Owner: [root]
                 Type: [weekly]
           Start date: [0/0/0]
         Days of week: [Fri]
             Run time: [2]:[0]
              Command: [/usr/syno/synoreport/synoreport -report  \S\p\e\i\c\h\e\r\n\u\t\z\u\n\g]
        Last Run Time: Fri Feb  9 02:00:02 2018
               Status: [Success]

    Meine Synology wacht noch 2 mal am Tag ungeplant auf:
    Code:
    Information,System,2018/02/08 18:51:19,SYSTEM,Internal disks woke up from hibernation.
    Information,System,2018/02/08 15:32:14,SYSTEM,Internal disks woke up from hibernation.
    Information,System,2018/02/07 18:51:18,SYSTEM,Internal disks woke up from hibernation.
    Information,System,2018/02/07 15:32:14,SYSTEM,Internal disks woke up from hibernation.
    Information,System,2018/02/06 18:51:18,SYSTEM,Internal disks woke up from hibernation.
    Information,System,2018/02/06 15:32:14,SYSTEM,Internal disks woke up from hibernation.
    Information,System,2018/02/05 18:51:17,SYSTEM,Internal disks woke up from hibernation.
    Information,System,2018/02/05 15:32:14,SYSTEM,Internal disks woke up from hibernation.
    Ein tägliches Aufwachen wird mit Speicher-Manager -> Volume -> Bearbeiten -> Dateizugriffsfrequenz aufzeichen: Täglich zusammenhängen.
    Die HibernationFull.log sagt z.B. das Journaling Block Device greift zu:

    Code:
    [517749.021761] jbd2/sda1-8(969): WRITE block 2199208 on sda1 (8 sectors)
    [517749.021776] jbd2/sda1-8(969): WRITE block 2199216 on sda1 (8 sectors)
    [517749.021790] jbd2/sda1-8(969): WRITE block 2199224 on sda1 (8 sectors)
    [517749.021802] jbd2/sda1-8(969): WRITE block 2199232 on sda1 (8 sectors)
    [517749.021815] jbd2/sda1-8(969): WRITE block 2199240 on sda1 (8 sectors)
    [517749.021846] ata1: wake up from deepsleep, reset link now
    [517749.032276] syslog-ng(1081): dirtied inode 20129 (disk.log) on sda1
    [517749.032412] syslog-ng(1081): dirtied inode 22465 (kern.log) on sda1
    [517749.032547] syslog-ng(1081): dirtied inode 22466 (messages) on sda1
    [517749.089595] ata1: device unplugged sstatus 0x100
    [517749.156449] syno_hibernatio(12295): dirtied inode 26869 (hibernation.log) on sda1
    [517749.156464] syno_hibernatio(12295): dirtied inode 26869 (hibernation.log) on sda1
    [517749.156470] syno_hibernatio(12295): dirtied inode 26869 (hibernation.log) on sda1
    [517749.156615] syno_hibernatio(12295): dirtied inode 19637 (hibernationFull.log) on sda1
    [517749.156624] syno_hibernatio(12295): dirtied inode 19637 (hibernationFull.log) on sda1
    [517749.156629] syno_hibernatio(12295): dirtied inode 19637 (hibernationFull.log) on sda1
    [517749.659967] syno_hibernatio(26558): dirtied inode 11 (bin) on sda1
    uptime : [517749.089595]
    ======Idle 74422 seconds======
    Thu Feb 8 15:32:02 CET 2018
    #####################################################
    ***********Clear*********
    ...
    [517746.998251] scemd(26543): dirtied inode 8414660 (enumlist_det.tmp) on tmpfs
    [517749.021735] jbd2/sda1-8(969): WRITE block 2199200 on sda1 (8 sectors)
    [517749.021761] jbd2/sda1-8(969): WRITE block 2199208 on sda1 (8 sectors)
    [517749.021776] jbd2/sda1-8(969): WRITE block 2199216 on sda1 (8 sectors)
    [517749.021790] jbd2/sda1-8(969): WRITE block 2199224 on sda1 (8 sectors)
    [517749.021802] jbd2/sda1-8(969): WRITE block 2199232 on sda1 (8 sectors)
    [517749.021815] jbd2/sda1-8(969): WRITE block 2199240 on sda1 (8 sectors)
    [517749.021846] ata1: wake up from deepsleep, reset link now
    [517749.032276] syslog-ng(1081): dirtied inode 20129 (disk.log) on sda1
    [517749.032412] syslog-ng(1081): dirtied inode 22465 (kern.log) on sda1
    [517749.032547] syslog-ng(1081): dirtied inode 22466 (messages) on sda1
    [517749.089595] ata1: device unplugged sstatus 0x100
    [517749.156449] syno_hibernatio(12295): dirtied inode 26869 (hibernation.log) on sda1
    ...

  4. #14
    Anwender
    Registriert seit
    26.08.2015
    Beiträge
    47

    Standard

    Bei mir lag es am CMS. Dort war meine OffSite Diskstation und eine Docker DSM registriert.
    Ich spare mir jetzt das CMS und verbinde mich direkt mit den DiskStations.

    DS918+ (DSM 6.1.5-15254)
    DS214se (Off-Site)

  5. #15
    Anwender
    Registriert seit
    19.02.2014
    Beiträge
    290

    Standard

    Hallo, ich häng mich mal hier ran, weil ich den Thread sehr hilfreich fand, um das Log überhaupt zu finden. Außerdem ist auch interessant, dass beim hier hochgeladenen Log ebenfalls dirtyinode vorkommt, was ich bei mir erstmal als nicht so gut interpretiert hatte. Meine Syno ist eine DS213e, also schon etwas älter. Ich habe einen Mail-Server mit Relay bei Strato darauf laufen und greife mit IMAP-clients darauf zu. Außerdem läuft eine Cloudstation, CalDAV-Server (über WebDAV) und CardDAV-Server. Ich nutze MailRelaxer, ein 3rd-Party tool zum Ermöglichen der Hibernation trotz Mail-Server. Nachts läuft außerdem eine Surveillance Station, dieser Service wird aber um ca. 0 Uhr gestartet und ca. 5 Uhr wieder beendet. Das hat eigentlich früher auch immer ganz gut funktioniert. Mittlerweile bin ich mir nicht mehr sicher, ob die Disk Station korrekt funktioniert. Erstens ist habe ich ständig Traffic. Die LAN-Lampe flackert dauernd, obwohl eigentlich niemand (im Haushalt hier) darauf zugreift. Selbst die clients, die CaldDAV etc nutzen synchronisieren ja nicht alle paar Minuten oder Sekunden, sondern eigentlich nur bei Änderung und ansonsten alle paar Stunden oder täglich. Ich sehe den Traffic auch an der Powerline-Buchse, die ich benutze. Im Log steht außerdem gelegentlich, dass die Disk-Hibernation beendet wurde. Leider wird ja nie protokolliert, wann sie begonnen hat. Aber in Abständen von 15 Minuten wird jedenfalls eine Hibernation, falls sie mal begann, immer beendet. Ich lade hier mal das Full Log hoch (einen kleinen Ausschnitt), denn ich kann da nichts erkennen. Die Datei konnte ich übrigens nicht anhängen, da "ungültige Datei".

    Würde mich über mehr oder weniger konkrete Hinweise freuen. Da das denke ich ein weit verbreitetes Thema ist könnte das ja auch anderen helfen.

    Code:
    [84867.970801] zip(19350): READ block 2361088 on md0 (24 sectors)
    [84868.023182] zip(19350): READ block 271856 on md0 (8 sectors)
    [84868.031187] zip(19350): READ block 270664 on md0 (8 sectors)
    [84868.031239] zip(19350): READ block 495224 on md0 (8 sectors)
    [84868.031281] zip(19350): READ block 757944 on md0 (8 sectors)
    [84868.031313] zip(19350): READ block 1118048 on md0 (8 sectors)
    [84868.031343] zip(19350): READ block 1128520 on md0 (8 sectors)
    [84868.031372] zip(19350): READ block 1125824 on md0 (8 sectors)
    [84868.031401] zip(19350): READ block 1330944 on md0 (8 sectors)
    [84868.031431] zip(19350): READ block 1337032 on md0 (8 sectors)
    [84868.031461] zip(19350): READ block 1348400 on md0 (8 sectors)
    [84868.031491] zip(19350): READ block 1358176 on md0 (8 sectors)
    [84868.031522] zip(19350): READ block 1351952 on md0 (8 sectors)
    [84868.031554] zip(19350): READ block 1342120 on md0 (8 sectors)
    [84868.031586] zip(19350): READ block 1334024 on md0 (8 sectors)
    [84868.031617] zip(19350): READ block 1368600 on md0 (8 sectors)
    [84868.031648] zip(19350): READ block 1373808 on md0 (8 sectors)
    [84868.031702] zip(19350): READ block 1379520 on md0 (136 sectors)
    [84868.075292] zip(19350): dirtied inode 28 (esynoscheduler.log) on md0
    [84868.084377] zip(19350): READ block 1379656 on md0 (248 sectors)
    [84868.084481] zip(19350): READ block 1379904 on md0 (248 sectors)
    [84868.084514] zip(19350): READ block 1380152 on md0 (16 sectors)
    [84868.097238] zip(19350): READ block 1380168 on md0 (248 sectors)
    [84868.097320] zip(19350): READ block 1380416 on md0 (8 sectors)
    [84868.097360] zip(19350): READ block 1646592 on md0 (8 sectors)
    [84868.097397] zip(19350): READ block 1652560 on md0 (8 sectors)
    [84868.097462] zip(19350): READ block 1655808 on md0 (248 sectors)
    [84868.097514] zip(19350): READ block 1656056 on md0 (136 sectors)
    [84868.097552] zip(19350): READ block 1661648 on md0 (64 sectors)
    [84868.097607] zip(19350): READ block 80896 on md0 (176 sectors)
    [84868.097649] zip(19350): READ block 1584672 on md0 (64 sectors)
    [84868.097683] zip(19350): READ block 1380800 on md0 (64 sectors)
    [84868.148947] zip(19350): READ block 1380864 on md0 (248 sectors)
    [84868.149023] zip(19350): READ block 1381112 on md0 (8 sectors)
    [84868.149095] zip(19350): READ block 1400832 on md0 (248 sectors)
    [84868.149164] zip(19350): READ block 1401080 on md0 (248 sectors)
    [84868.149226] zip(19350): READ block 1401328 on md0 (248 sectors)
    [84868.149252] zip(19350): READ block 1401576 on md0 (24 sectors)
    [84868.254345] zip(19350): READ block 1401600 on md0 (248 sectors)
    [84868.254450] zip(19350): READ block 1401848 on md0 (248 sectors)
    [84868.254519] zip(19350): READ block 1402096 on md0 (248 sectors)
    [84868.254579] zip(19350): READ block 1402344 on md0 (248 sectors)
    [84868.254609] zip(19350): READ block 1402592 on md0 (32 sectors)
    uptime : [84867.591701]
    ======Idle 21 seconds======
    Tue Jan 1 19:30:53 CET 2019
    #####################################################

  6. #16
    Anwender
    Registriert seit
    20.08.2016
    Beiträge
    12

    Standard

    Laut Log scheint ein Zip Prozess zu laufen, aber der relevante Ausschnitt ist nicht drauf.
    Bei so vielen Anwendungen die ständig laufen, wird immer eine Anwendung die Disks aufwecken. Bei Mailserver und Surveillance Station wäre es vielleicht besser die Diskstation durchlaufen zu lassen.

    Zum probieren:
    - Anwendungen vorübergehend deaktivieren und nacheinander aktivieren um die verursachende Anwendung zu finden, Mail Station und Surveillance Station beeinflussen Hibernation, siehe https://www.synology-wiki.de/index.p...Down_betreffen
    - Crontab prüfen, vielleicht ist ein Prozess alle paar Minuten eingeplant
    - Weitere Logs prüfen: Synosys und Synoconn
    - Diskstation vorübergend vom Netzwerk trennen (Kabel ziehen) und das Verhalten beobachten. Vielleicht liegt das Problem nicht an der Diskstation, sondern an einem anderen Gerät das ständig auf die Diskstation zugreift z.B. an einem Win7 PC mit Dateiindizierung.

  7. #17
    Anwender
    Registriert seit
    19.02.2014
    Beiträge
    290

    Standard

    Danke für die Antwort. Ich habe unabhängig davon die Syno mal vom Netz getrennt und da geht sie auch in den Ruhezustand.

    Das Log hatte ich mir über das Protokoll Center runtergeladen, indem ich dort "System" angehakt hatte und dann exportiert. Woher bekomme ich denn die anderen beiden Logs, die du ansprichst?

    Ein ZIP-Prozess sagt mir jetzt eigentlich nichts. Was sollte das für ein Prozess sein?

    Da die Syno ohne Netzwerkverbindung in den Ruhezustand geht habe ich überlegt welche Gründe das haben kann. Cloudstation käme in Frage, aber ich hatte auch vorher keinen client, der aktiv war. Möglich wäre eben auch noch eine Aktualisierung der Kalender von einem Telefon aus. Ich werde die Dienste in der Syno mal eine Zeitlang deaktivieren und beobachten.

  8. #18
    Anwender
    Registriert seit
    19.02.2014
    Beiträge
    290

    Standard

    Habe nun einmal WebDAV/CalDAV deaktiviert und einmal Cloudstation/Mail Server. In beiden Fällen bleibt die Syno aktiv und die LAN-Lampe flankert gelegentlich. Ich vermute also es gibt einen anderen Grund.

  9. #19
    Anwender
    Registriert seit
    20.08.2016
    Beiträge
    12

    Standard

    Von der LAN-Lampe solltest du dich nicht irritieren lassen. Aber wenn du die Diskstation vom LAN getrennt hast und sie geht in den Ruhezustand, dann wird vermutlich irgendein Device ( PC, Handy, sonstwas) darauf zugreifen z.B. mit Windows Broadcasting Paketen. Kannst du alle anderen Geräte im Netzwerk ausschalten und dann das Verhalten der Synology beobachten?

    Mit den Logfiles meine ich einmal das Protokoll-Center im DSM oder
    var/log/synolog/synoconn
    var/log/synolog/synosys
    var/log/hibernation
    var/log/hibernationFull

    https://www.synology.com/de-de/knowl...em_Hibernation

    Du solltest im DSM Support Center -> Support Dienste den Ruhezustand Debugging Modus aktivieren, damit alle Logfiles entsprechend aufzeichnen.

  10. #20
    Anwender
    Registriert seit
    19.02.2014
    Beiträge
    290

    Standard

    Ich hab jetzt mal Zeit gehabt was zu testen und festgestellt, dass die Syno in den Ruhezustand geht, wenn ich alle weitergeleiteten Ports am Router abschalte. Außerdem kann mein Router auch den Traffic je Port anzeigen. Jetzt habe ich den Port zum CardDAV wieder aktiviert und sie fährt prompt hoch zum synchronisieren eines Adressbuchs (hab ich aktiv angestoßen). Der Traffic scheint mit trotzdem etwas hoch. Ich frage mich, ob die Syno bei jeder Anfrage am Port aufwacht, auch wenn es nur ein Scanner ist, der checken will, ob ich ihm Zugang gewähre... Außerdem überlege ich jetzt CardDAV und WebDAV auf einen Raspberry umzuziehen, der sowieso immer läuft, damit ich die Syno nur für Cloudstation und so nutze, wenn ich sie wirklich brauche.

Seite 2 von 2 ErsteErste 12

Ähnliche Themen

  1. Antworten: 0
    Letzter Beitrag: 18.01.2017, 16:04
  2. TVHeadend Einträge in /var/log/mediasrv.log
    Von hadi im Forum Andere 3rd Party Anwendungen
    Antworten: 1
    Letzter Beitrag: 08.01.2014, 20:44
  3. Kuriose messages log einträge
    Von Fartman im Forum Sonstiges
    Antworten: 2
    Letzter Beitrag: 22.05.2013, 17:51
  4. Antworten: 4
    Letzter Beitrag: 12.08.2012, 22:03
  5. Log File / Auswertung der Homepage
    Von carver im Forum Webserver
    Antworten: 15
    Letzter Beitrag: 15.10.2010, 07:12

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •