/var/log/hal_lib.log quillt über vor lauter Fehlermeldungen

    Hallo,
    nachdem ich ja mit alle Versionen von 4.2 auf meinem TS651 nur Probleme hatte (ultralangsame gui beim Setzen der Sambazugriffrechte, not clean file system, manaRequest.cgi scripts die ständig die ganze CPU geblockt haben ...) bin ich schon seit Mitte November wieder mit 4.1.4 unterwegs.
    Allerdings scheint es auch hier ein(ige) Problem zu geben - wie ich heute festgestellt habe starten auch hier jetzt alle paar Minuten manaRequest.cgi Skripte und die müllen mir zusammen mit diversen anderen Dingen die /var/log/hal_lib.log zu - ich hatte dieses log auch vor >1 Monat im Rahmen meines offenen 4.2 tickets an den deutschen Support geschickt, wie wohl üblich herrscht da jetzt seit 3 Wochen Funkstille ...


    Jetzt sieht es aber so aus, als wäre das gar nicht 4.2 spezifisch.
    Weiß jemand wo die ganzen Meldungen herkommen - das sind nur ein paar Sekunden aber es könnte erklären, warum meine Platten überhaupt nicht zur Ruhe kommen?


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

    Ich bin von dem gleichen Problem betroffen und bitte um Beantwortung dieser Frage.

    Folgende log files werden minütlich angefasst um jeweils Meldungen nach dem gelisteten Muster anzuhängen und lassen daher keine Festplatten einschlafen:

    hal_lib.log:

    Code
    2019-01-20 10:18:13 [ 591 hal_daemon ] id = 1, name = SATA_R-Error_Count, status_flag = 0x32, value = 200,worst = 200, thresh = 0,raw = 0
(repeating for id = 2~199)
2019-01-20 10:18:13 [ 591 hal_daemon ] id = 200, name = Multi_Zone_Error_Rate, status_flag = 0x8, value = 100,worst = 253, thresh = 0,raw = 0
2019-01-20 10:18:21 [ 591 hal_daemon ] GPIO_Set_NAS_Status_LED: event = 0x1000,status = 0, value = 0x0, formatting_count = 0
2019-01-20 10:18:21 [ 591 hal_daemon ] GPIO_Set_NAS_Status_LED: event = 0x2000,status = 0, value = 0x0, formatting_count = 0

    storage_lib.log:

    Code
    2019-01-20 10:15:21 [29256 manaRequest.cgi] Blk_Dev_Generate_Mount_Point: mount point for "/dev/mapper/cachedev1" is "/share/CACHEDEV1_DATA", is_internal is 1.
    2019-01-20 10:15:23 [29314 manaRequest.cgi] Volume_Enumerate_Data_Volumes: got called with (0xffb830, 772).
    2019-01-20 10:15:23 [29314 manaRequest.cgi] Blk_Dev_Generate_Mount_Point: mount point for "/dev/mapper/cachedev1" is "/share/CACHEDEV1_DATA", is_internal is 1.
    2019-01-20 10:15:26 [29335 authLogin.cgi ] Perform cmd "/bin/mount | grep "/mnt/HDA_ROOT" &>/dev/null" OK, cmd_rsp=0, reason code:0.
    2019-01-20 10:15:31 [29378 manaRequest.cgi] Volume_Enumerate_Data_Volumes: got called with (0x16da110, 772).
    2019-01-20 10:15:31 [29378 manaRequest.cgi] Blk_Dev_Generate_Mount_Point: mount point for "/dev/mapper/cachedev1" is "/share/CACHEDEV1_DATA", is_internal is 1.
    2019-01-20 10:15:33 [ 591 hal_daemon ] Volume_Enumerate_Data_Volumes: got called with (0x7f3124001240, 772).
    2019-01-20 10:15:33 [ 591 hal_daemon ] Blk_Dev_Generate_Mount_Point: mount point for "/dev/mapper/cachedev1" is "/share/CACHEDEV1_DATA", is_internal is 1.
    2019-01-20 10:15:34 [29420 manaRequest.cgi] Volume_Enumerate_Data_Volumes: got called with (0x1d95830, 772).
    2019-01-20 10:15:34 [29420 manaRequest.cgi] Blk_Dev_Generate_Mount_Point: mount point for "/dev/mapper/cachedev1" is "/share/CACHEDEV1_DATA", is_internal is 1.

    SDMD.log:

    Code
    SDM: start predict enc = 0 port = 1 device
SDM_Health_Predict:Start to predict sata disk
(repeating two lines for port = 2 ~8 device)
SDM: scan 32th enc, total enc = 4
SDM: enc = 32 is not internal.
SDM: scan 33th enc, total enc = 4
SDM: enc = 33 is not internal.
SDM: scan 34th enc, total enc = 4
SDM: enc = 34 is not internal.

    ini_config.log:

    Code
    Ini_Conf_Remove_LCK_File: lck file /var/lock/INI_L2V0Yy92b2x1bWUuY29uZg==.lck does not exist!

    Muss eventuell das manaRequest-script seltener ausgeführt werden?

    Verbirgt sich dahinter ein Flush-Vorgang?
    Liegt alles an falschem Journalling?

  • dr_mike

    Hat das Thema geschlossen.