rsync logging deaktivieren

    Hallo,


    wir haben zwei TS-1270U und replizieren die Daten von dem einen NAS zu dem Anderen per NAS-to-NAS Replication. Dabei wird die /HDA_ROOT/ Partition mit log-Dateien von rsync gefüllt, bis diese überläuft. Dies ist nicht tragisch, aber wenn das NAS neustartet wird das Volume nicht mehr gemountet.
    Auch nachdem ich die log-Dateien gelöscht habe wird wie Partition weiter befüllt. In die Datei wird die Standard-Ausgabe von rsync gespeichert und ist damit auch wenig sinnvoll.
    Zu replizieren sind knapp 7 Mio. Dateien mit einer Größe von ca. 12 TB.


    Ich habe bereits mehrere Tickets bei QNAP offen, erhalte aber keine Antworten. Dies ist auch nicht der einzige Fehler, aber der gravierendste.

    hmm -- kein großes Problem :)
    ich müsste mal sehen, wie das bei dir ausschaut -- dann bauen wir ein Shell-Script, was per Cron 1x am Tag durchgeht und die Files "killt" :)
    ist keine Große Sache ...

    Ich denke ich habe das Problem noch nicht richtig geschildert. Die Partition wird auch weiter gefüllt, obwohl ich die Dateien gelöscht habe.


    Vielleicht hilft dies weiter:


    Der Speicherplatz verbrauch der vorhandenen Dateien ist ca. 100MB

    Code
    du -H -s HDA_ROOT/du: WARNING: use --si, not -H; the meaning of the -H option will soonchange to be the same as that of --dereference-args (-D)98M     HDA_ROOT/


    Die Auslastung der Partition liegt bei 100%, obwohl 500MB zur Verfügung stehen.

    Code
    /dev/md9                509.5M    509.5M         0 100% /mnt/HDA_ROOT

    was sagt die Ausgabe von df?


    mir war gestern das root (/) zugelaufen -- ein reboot der box hats gerichtet ....
    ich müsste dann wissen, wo die rsync-Files liegen und wie die heißen

    Zitat von "Cerberus"

    as sagt die Ausgabe von df?


    Zitat von "joernahlers"

    Die Auslastung der Partition liegt bei 100%, obwohl 500MB zur Verfügung stehen.

    Code
    /dev/md9                509.5M    509.5M         0 100% /mnt/HDA_ROOT


    Die logs liegen unter /mnt/HDA_ROOT/.logs/rsync. Ich habe/hatte dort folgende Dateien:

    Code
    rsync-err-Schedule0
rsync-out-Schedule0
rsync-tmp-Schedule0


    Problematisch war die rsync-out-Schedule0 welche unbegrenzt wächst. Grstern nach einem Neustart konnte daher das Volume nicht gemountet werden. Nachdem das NAS wieder lief und die Replication gestartet haben konnte ich feststellen, dass die Datei wieder wächst. Dann habe ich die Deiei einfach gelöscht. Naja heute morgen war die Datei immer noch nicht vorhaben, aber die Partition voll. Nun werde ich aber auch das NAS nicht neustarten, ohne dass die Replication durchgelaufen ist. Der Ausfall des Gerätes wäre tragisch.

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

    das ist einfach zu "beheben" ...
    ich bau die mal eine .sh -- die macht erst mal ne Ausgabe in eine Datei ....
    die brauch ich dann hier .... oder per PM -- oder sonst irgendwie ...
    wenn sie die richtigen Treffer hat, kommt der Delete rein -- das ganze dann in den crontab -- und dein "Problem" ist geschichte


    --- ModEdit ---


    hier das Script:


    name ist im grunde egal -- ich habs bei mir in /share/MD0_DATA/homes liegen => Rechte: 700


    dann mir die info.txt (den Inhalt) zukommen lassen

    Einmal editiert, zuletzt von dr_mike () aus folgendem Grund: Doppelte Beiträge vermeiden, siehe Forenregeln! Bitte den 'Ändern' Button verwenden.

    Ok das script erzeugt eine leere info.txt . Das Problem sind auch nicht die vorhandenen Dateien. Die Verbrauchen auf der gesamten Partition nur ca. 100MB. Die Partition wird leider auf andere Weise gefüllt. Zudem ist das Verhalten der Replication falsch. Wieso werden die Standard-Ausgaben von rsync geloggt, dies muss deaktiviert werden. Das Problem wird nicht auftreten wenn mach ein paar Tausend Dateien repliziert, aber bei mehren Millionen läuft der Speicherplatz zwangsläufig über.

    leider ist es hier genau das gleiche wie bei den SAMBA-Logs ...
    der Pfad ist falsch eingestellt und verweist auf die extrem kleine /mnt


    könntest du mir mal die Ausgabe von ls -al im Verzeichnis '/mnt/HDA_ROOT/.logs/rsync' posten
    eine bessere Lesbarkeit erreichst du, wenn die Ausgabe ich eine Code-Box geschrieben wird


    PS: hat du rebootet?

    Zitat von "Cerberus"

    PS: hat du rebootet?


    Das werde ich erst machen, nachdem die Sicherung durchgelaufen ist.


    Hier die Ausgabe für das Verzeichnis /mnt/HDA_ROOT/.logs/rsync/


    Code
    # ls -al
drwxr-xr-x    2 admin    administ      4096 Jun 25 08:40 ./
drwxr-xr-x    5 admin    administ      4096 Jun 25 03:30 ../
-rw-r--r--    1 admin    administ         0 Jun 24 09:13 rsync-err-Schedule0
-rw-r--r--    1 admin    administ         0 Jun 24 09:13 rsync-tmp-Schedule0

    ich hab gerade mal nachgeprüft -- bei einem Kunden habe ich auch eine Auto-Sicherung über die WEB-Oberfläche laufen ....
    dort gibt es solche Ordner nicht -- die kommen von einer anderen Stelle ....

    die Files sind leer ...
    stellt dich mal in root und mach von dort noch mal ein df

    Vielleicht macht folgende Ausgabe die Sache verständlicher:

    Code
    [/mnt/HDA_ROOT] # du -H .du: WARNING: use --si, not -H; the meaning of the -H option will soonchange to be the same as that of --dereference-args (-D)455k    ./.qpkg/QNAP_Diagnostic_Tool459k    ./.qpkg1.2M    ./.driver4.1k    ./.cups/lpd4.1k    ./.cups/smb/64.1k    ./.cups/smb/24.1k    ./.cups/smb/44.1k    ./.cups/smb/34.1k    ./.cups/smb/74.1k    ./.cups/smb/529k     ./.cups/smb4.1k    ./.cups/cups/tmp8.2k    ./.cups/cups46k     ./.cups89M     ./update_pkg21k     ./.config/.qos_config/login8.2k    ./.config/.qos_config/users/scanner8.2k    ./.config/.qos_config/users/bilddb4.1k    ./.config/.qos_config/users/admin25k     ./.config/.qos_config/users50k     ./.config/.qos_config119k    ./.config/emap17k     ./.config/qsync201k    ./.config/storage_usage_history13k     ./.config/ssmtp4.1k    ./.config/torrent/torrent4.1k    ./.config/torrent/downloadinfo13k     ./.config/torrent29k     ./.config/ups25k     ./.config/stunnel21k     ./.config/ssh8.2k    ./.config/ntp4.1k    ./.config/mtp4.1k    ./.config/.qsys8.2k    ./.config/vaultServices50k     ./.config/openvpn/keys54k     ./.config/openvpn4.1k    ./.config/license/.req4.1k    ./.config/license/.lc4.1k    ./.config/license/.gnupg21k     ./.config/license13k     ./.config/openldap8.2k    ./.config/php.d4.1k    ./.config/.hd_info33k     ./.config/logo689k    ./.config/rssdoc37k     ./.config/lvm/archive13k     ./.config/lvm/backup54k     ./.config/lvm87k     ./.config/apache/extra62k     ./.config/apache/original/extra82k     ./.config/apache/original279k    ./.config/apache4.1k    ./.config/lunporter8.2k    ./.config/symform4.1k    ./.config/cups/ppd25k     ./.config/cups3.2M    ./.config25k     ./.logs/qsync4.1k    ./.logs/.qsync_log_queue4.1k    ./.logs/rsync1.4M    ./.logs17k     ./lost+found4.1k    ./.inited2.1M    ./ssl_lib98M     .


    Dazu die disk free Ausgabe:

    Code
    [/mnt/HDA_ROOT] # df
Filesystem                Size      Used Available Use% Mounted on
none                    200.0M    137.0M     63.0M  68% /
devtmpfs                  1.9G      4.0k      1.9G   0% /dev
tmpfs                    64.0M      2.3M     61.7M   4% /tmp
tmpfs                     1.9G         0      1.9G   0% /dev/shm
/dev/md9                509.5M    509.5M         0 100% /mnt/HDA_ROOT
/dev/mapper/cachedev1    18.9T     11.2T      7.7T  59% /share/CACHEDEV1_DATA
/dev/md13               371.0M    335.5M     35.5M  90% /mnt/ext


    Scheinbar hat QNAP in der Firmware wieder Mist gebaut, was leider häufiger vorkommt. Aber es muss irgendwo die Möglichkeit geben das logging zu unterbinden.

    soweit ich das sehen kann, läuft hier ein anderes Verzeichnis zu ...
    die reinen Größen passen nicht, um auch nur annähernd 500MB zu erreichen ...


    check doch mal die untergeordneten Verzeichnisse ...
    irgend eines davon ist so groß, das es dir die Probleme macht ...


    und das mit den LOG-Pfaden => so what => ist bekannt :) -- leider

    Zitat von "Cerberus"


    check doch mal die untergeordneten Verzeichnisse ...
    irgend eines davon ist so groß, das es dir die Probleme macht ...


    Es gibt nicht mehr hier noch die Ausgabe des Verbrauchs mit Dateien


    Leider erreicht man bei QNAP über den Chal als auch über Hotline keinen verantwortlichen. Naja dann muss ich mal gucken wie es sich entwickelt.

    wie zu sehen ist, liegt das Problem nicht bei rsync ...
    diese Files sind leer -- es muss eine andere Ursache haben ...
    eventuell ist ein Verzeichnis als Link eingehängt oder etwas anderes "knall" das Laufwerk zu ...
    ich würde empfehlen, erst mal den reboot zu machen ...
    dann lässt sich eher etwas erkennen


    :edit -- welche FW ist drauf ....
    die Fehlermeldung von du macht mich stutzig ...
    ich bekomme die auf keiner Box zu gesicht

    Kann es sein dass du eine alte Firmware (4.0.x?) hast und Opfer der Shellshock Lücke wurdest?


    machmal bitte

    Code
    which du


    und schau ob du noch die normalen busybox installationen hast. Bei meiner NAS liegt du in /usr/bin/du
    Wenn bei dir da was anderes steht (von dem ich ausgehe, da du eine neuere du version hast, die es bei Qnap eigentlich nicht gibt), wars wohl der Shellshock. Irgendwo hier geistert auch ein thread dazu rum, wo das beschrieben ist:
    http://forum.qnapclub.de/viewtopic.php?f=242&t=8721 genereller Was nun thread
    http://forum.qnapclub.de/viewtopic.php?f=25&t=32959 shellshock thread


    Grüße,


    Acid

    Hallo die beiden NAS laufen mit FW 4.1.4 und das ist alles normal mit busybox.


    Leider gibt es kein iotop damit ich mir ausgeben lassen kann welche Prozesse die Last auf der Partition verursachen aber hier die Ausgabe von iostat

    Code
    [/mnt/HDA_ROOT] # iostat -d md9
      md9
  kps tps svc_t
  488 122   0.0


    Ich gehe davon aus, dass rsync das Problem verursacht. Rsync hat bereits zuvor eine log-Datei geschrieben die den Speicherplatz zum überlaufen gebracht hat. Nach dem Neustart konnte daher das Volume nicht gemountet werden. Dieser Fehler konnte durch das Löschen der Log-Dateien gelöst werden. Nach dem Neustart war alles wieder in Ordnung. Rsync habe ich wieder gestartet und die log Datei wurde wieder größer. Damit das vorherige Problem nicht wieder auftritt habe ich die Log-Datei gelöscht. Damit wurde der Speicherplatz freigegeben, aber dennoch ist die Festplattenauslastung weiter angestiegen. Ich gehe nun davon aus, dass rsync einfach auch ohne Datei an der Speicherposition weiter auf die Partition schreibt, an der ich die Datei gelöscht habe.

    such dir mal bei den Scripten mein Script für die CoreUtils raus ...
    das rüstet sehr viele Sachen nach -- ach atop :)


    du kannst auch mit

    Code
    ipkg install iotop


    das Tool nachrüsten :)

    Ich hatte grade eine Stunde mit einem Support Mitarbeiter und einem QNAP Entwickler eine Teamviewer Session. Beiden konnte ich das Problem darstellen, aber eine Lösung konnte nicht gefunden werden. Es ist ein Fehler der in dem nächsten Release behoben wird.

    Das Problem ist, dass dem rsync Prozess das Logfile im Betrieb weggezogen wurde und der Speicherplatz nicht freigegeben wird obwohl die Datei oder sagen wir besser der Link gelöscht ist. Wenn Dein sync durch ist, mal versuchen den rsync Server zu stoppen und neu zu starten. Wenn das nicht hilft einen Reboot durchführen.
    Man könnte während des Boots einen Softlink für das .rsync Verzeichnis auf eine Deiner Datenplatten setzen (die vom sync ausgeschlossen ist ;) )
    Nicht sehr elegant, aber würde den Zweck erfüllen.