Ich hätte da mal einige Fragen zu (siehe Topic)
Nachdem ich mit den Befehlen
psql mediaserver postgres
SELECT COUNT(*) AS music_count FROM music;
oder
SELECT * FROM music WHERE id = (SELECT MAX (id) FROM music);
zumindest mal klären konnte ob meine mediaindizierung überhaupt noch läuft und falls ja (dem war so) wie weit sie denn nach 5 Tagen á 24h schon gekommen ist habe ich als nächstes mal ein Blick in doch hinsichtlich Iherer Größe respektablen log Dateien geworfen.
Mehrere davon >20MB finde ich schon arg innerhalb von nicht mal einem Monat Betrieb.
in der messages war's recht einfach die Ursache zu finden.
Der vermutlich etwas ältere Programmierer bei synology der die AudioStation verantwortet hatte wohl vor 15 Jahren im Rahmen von mp3 und ID3v1.x den glorreichen Einfall das 128 chars für das Genrefeld ausreichend sind. Also immer brav 5 Zeilen im Logfile für schlechte Programmierung, damit kann ich leben, denn ich kenne die Ursache.
Aber weiter in den Logfiles.
mein syslog.log hat endlose Zeilen in der Abfolge
syslog-ng[4096]: Referenced filter rule not found in filter() expression; rule= 'f-synodr_replica_progress'
syslog-ng[4095]: Configuration reload request received, reloading econfiguration;
ab und an mal gefolgt von syslog-ng shutting down; version '3.5.5.' und einem starting up.
Dann wieder Kilometerlang die o.g. Zeilenkombination.
Hat jemand ne Idee von welchem Filter hier geredet wird ?
Was ich auch nicht verstehe ich warum mein fileindexd.log demnächst die 10MB Grenze erreicht und rand voll ist mit Einträgen wie der folgende:
fileindexd: fs_document.cpp:125 (fs_document.cpp:125)(No such file or directory)Failed [jsData.isNull() || !jsData.isObject() || !jsData.isMember(SZ_RESPONSE_KEY_SUCCESS) || !jsData[SZ_RESPONSE_KEY_SUCCESS].asBool() || !jsData.isMember(SZ_RESPONSE_KEY_DATA) || !jsData[SZ_RESPONSE_KEY_DATA].isObject()], err=No such file or directory
Vom synocontentextractd.log muss man gar nicht erst reden, das kann man genaugenommen ja direkt täglich mit >logfilename leeren.
Irre. Jede 2te Zeile ein Error.
Ist das grundsätzlich alles völlig normal? Ich bin weder mit den NAS noch mit Linux sonderlich firm, aber so viel unterscheidet sich das NAS nun nicht von den Linux-SAT-Receivern, da kämpfe ich dann allerdings nicht mit Logfiles in diesen Dimensionen und vor allem nicht mit derart vielen Fehlereinträgen die ohne tiefere Kenntnisse keinen Rückschluss auf das tatsächliche Problem (so es denn eins ist).
Kurzum, gibts hier irgendwo im Forum einen Thread den ich übersehen habe in dem mal erklärt wird welche Probleme in welchem log zu finden sind, auf was man ggf. achten sollte, und habe ich eigentlich eine Möglichkeit die Loglevel irgendwo einzustellen?
Und letzte Frage, kann ich *,log im /var/log alle bedenkenlos plätten, um überhaupt mal wieder ne Chance zu bekommen neu auftretende Einträge zu lokalisieren? oder ist's besser die Dateien nur zu leeren?
bin für jeden Tipp dankbar
Nachdem ich mit den Befehlen
psql mediaserver postgres
SELECT COUNT(*) AS music_count FROM music;
oder
SELECT * FROM music WHERE id = (SELECT MAX (id) FROM music);
zumindest mal klären konnte ob meine mediaindizierung überhaupt noch läuft und falls ja (dem war so) wie weit sie denn nach 5 Tagen á 24h schon gekommen ist habe ich als nächstes mal ein Blick in doch hinsichtlich Iherer Größe respektablen log Dateien geworfen.
Mehrere davon >20MB finde ich schon arg innerhalb von nicht mal einem Monat Betrieb.
in der messages war's recht einfach die Ursache zu finden.
Der vermutlich etwas ältere Programmierer bei synology der die AudioStation verantwortet hatte wohl vor 15 Jahren im Rahmen von mp3 und ID3v1.x den glorreichen Einfall das 128 chars für das Genrefeld ausreichend sind. Also immer brav 5 Zeilen im Logfile für schlechte Programmierung, damit kann ich leben, denn ich kenne die Ursache.
Aber weiter in den Logfiles.
mein syslog.log hat endlose Zeilen in der Abfolge
syslog-ng[4096]: Referenced filter rule not found in filter() expression; rule= 'f-synodr_replica_progress'
syslog-ng[4095]: Configuration reload request received, reloading econfiguration;
ab und an mal gefolgt von syslog-ng shutting down; version '3.5.5.' und einem starting up.
Dann wieder Kilometerlang die o.g. Zeilenkombination.
Hat jemand ne Idee von welchem Filter hier geredet wird ?
Was ich auch nicht verstehe ich warum mein fileindexd.log demnächst die 10MB Grenze erreicht und rand voll ist mit Einträgen wie der folgende:
fileindexd: fs_document.cpp:125 (fs_document.cpp:125)(No such file or directory)Failed [jsData.isNull() || !jsData.isObject() || !jsData.isMember(SZ_RESPONSE_KEY_SUCCESS) || !jsData[SZ_RESPONSE_KEY_SUCCESS].asBool() || !jsData.isMember(SZ_RESPONSE_KEY_DATA) || !jsData[SZ_RESPONSE_KEY_DATA].isObject()], err=No such file or directory
Vom synocontentextractd.log muss man gar nicht erst reden, das kann man genaugenommen ja direkt täglich mit >logfilename leeren.
Irre. Jede 2te Zeile ein Error.
Ist das grundsätzlich alles völlig normal? Ich bin weder mit den NAS noch mit Linux sonderlich firm, aber so viel unterscheidet sich das NAS nun nicht von den Linux-SAT-Receivern, da kämpfe ich dann allerdings nicht mit Logfiles in diesen Dimensionen und vor allem nicht mit derart vielen Fehlereinträgen die ohne tiefere Kenntnisse keinen Rückschluss auf das tatsächliche Problem (so es denn eins ist).
Kurzum, gibts hier irgendwo im Forum einen Thread den ich übersehen habe in dem mal erklärt wird welche Probleme in welchem log zu finden sind, auf was man ggf. achten sollte, und habe ich eigentlich eine Möglichkeit die Loglevel irgendwo einzustellen?
Und letzte Frage, kann ich *,log im /var/log alle bedenkenlos plätten, um überhaupt mal wieder ne Chance zu bekommen neu auftretende Einträge zu lokalisieren? oder ist's besser die Dateien nur zu leeren?
bin für jeden Tipp dankbar
