Fakelog und nrarchive funktioniert nicht für das globale FHEM Log..

[Rampler]

Hallo zusammen,
mein FHEM Log würde ich gerne zwei Monate haben ! Aus diesem Grund habe ich nrarchive auf 1 gesetzt, jedoch habe ich immer nur das aktuelle Log. Im aktuellen Log sehe ich auch diese Meldung:

Code Auswählen Erweitern

2017.02.01 00:00:02 2: Deleting fhem-2017-01.log

Ein List Logfiel ergibt:

Code Auswählen Erweitern

Internals:
   DEF        ./log/fhem-%Y-%m.log fakelog
   NAME       Logfile
   NR         15
   NTFY_ORDER 50-Logfile
   REGEXP     fakelog
   STATE      active
   TYPE       FileLog
   currentlogfile ./log/fhem-2017-02.log
   logfile    ./log/fhem-%Y-%m.log
   Readings:
     2017-02-01 00:00:02   linesInTheFile  0
Attributes:
   icon       time_note
   nrarchive  1
   room       FHEM

Sieht für mich aus, als ob das nrachive für das FHEM Log nicht greift.
Für alle meine anderen Log's funktioniert es erwartungsgemäß.
Log-archive habe ich bewusst nicht gesetzt, da ich für dieses Log keine Archivierung benötige.
Testweise habe ich mal ein altes Log in das FHEM Log Verzeichnis kopiert, dieses wird dann bei Neustart wieder gelöscht.

Habe ich einen Denkfehler ?

bis dann
  Klaus

[KernSani]

Nrarchive = 1 bedeutet, dass ein File im Log folder behalten wird, works as designed...

[betateilchen]

@KernSani: Das ist falsch. nrarchive=1 bedeutet, dass EIN File zusätzlich zum aktuellen behalten wird.

@Rampler: Dein Denkfehler ist ein anderer. Hast Du das nrarchive auch in global entsprechend gesetzt? Dort ist für das fakelog die tatsächlich entscheidende Stelle, nicht in der FileLog Definition.

[Rampler]

@Rampler: Dein Denkfehler ist ein anderer. Hast Du das nrarchive auch in global entsprechend gesetzt? Dort ist für das fakelog die tatsächlich entscheidende Stelle, nicht in der FileLog Definition.

Sorry, muss leider enttäuschen..

Code Auswählen Erweitern

Internals:
   DEF        no definition
   NAME       global
   NR         1
   STATE      no definition
   TYPE       Global
   currentlogfile ./log/fhem-2017-02.log
   logfile    ./log/fhem-%Y-%m.log
Attributes:
   autoload_undefined_devices 1
   configfile fhem.cfg
   latitude   50.0712
   logfile    ./log/fhem-%Y-%m.log
   longitude  10.207
   modpath    .
   motd       Have Fun !!!
   nrarchive  1
   room       FHEM
   sendStatistics onUpdate
   statefile  ./log/fhem.save
   userattr   cmdIcon devStateIcon devStateStyle icon sortby webCmd widgetOverride
   verbose    3
   version    fhem.pl:13142/2017-01-18

[betateilchen]

Sieht für mich aus, als ob das nrachive für das FHEM Log nicht greift.

Es funktioniert definitiv auch für das fakelog, zumindest bei Werten > 1 (ich habe nrarchive auf 3 stehen). Mit 1 habe ich noch nie getestet, werde ich aber mal machen. Bei mir gibts Tageslogs, da ist das relativ einfach zu testen, das interessiert mich jetzt

Mal schauen, wie es dann morgen früh aussieht.

[Rampler]

Mal schauen, wie es dann morgen früh aussieht.

Gespannt bin ..

[KernSani]

@KernSani: Das ist falsch. nrarchive=1 bedeutet, dass EIN File zusätzlich zum aktuellen behalten wird.

Ups, da muss ich wohl nochmal commandref lesen... Hatte das flag erst kürzlich auf 7 gesetzt und dachte ich hätte tatsächlich auch 7 files inkl. des aktuellen gehabt. Stelle jetzt aber fest, dass ich aktuell 9 files habe... werde auch mal bis morgen warten...

[betateilchen]

Nach dem Umstellen von nrarchive=3 auf nrarchive=1 lief alles wie geplant:

Code Auswählen Erweitern


2017.02.17 00:00:06 2: Deleting fhem-13.log
2017.02.17 00:00:06 2: Deleting fhem-14.log
2017.02.17 00:00:06 2: Deleting fhem-15.log


und geblieben ist das aktuelle Logfile + das Logfile von gestern (siehe Screenshot im Anhang)

[Rampler]

@betateilchen
Dank Dir für den Test 

Ok, heißt also, dass ich ein Problem habe.
Habe allerdings keinen Plan mehr, wie ich das weiter einschränken kann, für weitere Tips bin ich dankbar..

bis dann
  Klaus

[betateilchen]

fhem.pl und 01_FHEMWEB.pm sind bei Dir aktuell?

[Rampler]

fhem.pl und 01_FHEMWEB.pm sind bei Dir aktuell?

fhem.pl:
# $Id: fhem.pl 13142 2017-01-18 14:23:53Z rudolfkoenig $

01_FHEMWEB.pm:
# $Id: 01_FHEMWEB.pm 13162 2017-01-21 08:36:35Z rudolfkoenig $

[Rampler]

Habe den Fehler gefunden...
Nach löschen vom Attr nrarchive beim Global funktioniert es nun. War vorher auf 1.
Bleibt trotzdem merkwürdig, aber egal, jetzt funktioniert es ja..
Danke nochmal, für eure Hilfe..

VG
Klaus

[betateilchen]

# $Id: 01_FHEMWEB.pm 13162 2017-01-21 08:36:35Z rudolfkoenig $

Das ist aber nicht die aktuelle Version.

[Rampler]

Es ist zum Mäuse melken...
Mehrmaliges durchstarten von FHEM oder dem RPI, das vorherige Filelog bleibt erhalten.
Jetzt nach Monatswechsel wieder:

Code Auswählen Erweitern

2017.03.01 00:00:02 2: Deleting fhem-2017-01.log
2017.03.01 00:00:02 2: Deleting fhem-2017-02.log

Code Auswählen Erweitern

Internals:
   DEF        ./log/fhem-%Y-%m.log fakelog
   NAME       Logfile
   NR         15
   NTFY_ORDER 50-Logfile
   REGEXP     fakelog
   STATE      active
   TYPE       FileLog
   currentlogfile ./log/fhem-2017-03.log
   logfile    ./log/fhem-%Y-%m.log
   Readings:
     2017-03-01 00:00:02   linesInTheFile  0
Attributes:
   alias      Logfile_FHEM
   icon       time_note
   nrarchive  1
   room       FHEM

Code Auswählen Erweitern

Internals:
   DEF        no definition
   NAME       global
   NR         1
   STATE      no definition
   TYPE       Global
   currentlogfile ./log/fhem-2017-03.log
   logfile    ./log/fhem-%Y-%m.log
Attributes:
   autoload_undefined_devices 1
   configfile fhem.cfg
   latitude   50.0712
   logfile    ./log/fhem-%Y-%m.log
   longitude  10.207
   modpath    .
   motd       Have Fun !!!
   room       FHEM
   sendStatistics onUpdate
   statefile  ./log/fhem.save
   userattr   cmdIcon devStateIcon devStateStyle icon sortby webCmd widgetOverride
   verbose    3
   version    fhem.pl:13411/2017-02-14

Habe noch zwei weitere FHEM Instanzen (FHEM2FHEM), da wurde nichts gelöscht. Diese laufen allerdings auch unter Openwrt/LEDE, und nicht auf einem Raspberry.
Kann ich gar nicht glauben, dass ich der einzige bin, mit diesem Problem.

bis die Tage
   Klaus

[rudolfkoenig]

Ich gehe davon aus, dass die neulich eingefuehrte Methode fuer das Bestimmen der Dateireihenfolge daran Schuld ist. Bis vor kurzem wurde die Reihenfolge anhand Dateinamen bestimmt, seit kurzem nach dem Zeitstempel der letzten Aenderung. Wenn man alte Dateien (evtl unbewusst) modifiziert, dann werden sie nicht wie erwartet entfernt.

Ich habe aus diesem Grund das Filelog und global Attribut "archivesort" eingefuehrt, mit den moeglichen Werten alphanum und timestamp. Default ist alphanum, so wie frueher.
@betateilchen: du musst timestamp (leider) explizit fuer alle Filelogs + global setzen