HI!
Ich habe etwas aufgeräumt und unter global das attr logfile auf ./log/fhem-%Y-%m-%d.log fakelog gesetzt sowie unter Logfile das gleiche in der DEF. und das attribut nrarchive 7.
Nun wird mein Log gar nicht mehr beschrieben... Es existieren 2 Dateien, von gestern eine und von heute eine aber beide sind leer. Neustart hat leider leinen Erfolg gebracht.
Drücke ich links im Fenster auf Logfile wird auch nichts angezeigt...
Hilfe! Hat jemand eine Idee was passiert ist und wie ich das wieder hinbekomme?
Moin,
poste bitte:
list global logfile currentlogfile
list Logfile
Wenn das da wirklich steht ist es falsch, fakelog hat da nichts zu suchen:
Zitat von: misux am 27 Dezember 2021, 01:41:56
Ich habe etwas aufgeräumt und unter global das attr logfile auf ./log/fhem-%Y-%m-%d.log fakelog gesetzt
Schau Dir die Original fhem.cfg an
https://svn.fhem.de/trac/browser/trunk/fhem/fhem.cfg
Gruß Otto
Habe jetzt im global das fakelog gelöscht... aber im Logfile in der DEF lässt er mich das nicht löschen...
wrong syntax: define <name> FileLog filename regexp [readonly]
Siehe Bild...
List Logfile:
Internals:
DEF ./log/fhem-%Y-%m-%d.log fakelog
FD 6
FUUID 6011a46c-f33f-e7ed-b772-cfa590efe9bd6dfa
NAME Logfile
NR 6
NTFY_ORDER 50-Logfile
REGEXP fakelog
STATE active
TYPE FileLog
currentlogfile ./log/fhem-2021-12-27.log
logfile ./log/fhem-%Y-%m-%d.log
READINGS:
2021-12-27 00:00:01 linesInTheFile 0
Attributes:
nrarchive 7
room Entwicklung
Global nach änderung:
global logfile ./log/fhem-%Y-%m-%d.log fakelog
currentlogfile ./log/fhem-2021-12-27.log
Das mit dem Fakelog hatte ich hier im Forum gefunden und übernommen... Hmmm.. war wohl nicht richtig...
Hier her habe ich das mir dem fakelog... dachte das wäre in Ordnung...
https://forum.fhem.de/index.php/topic,62987.msg542733.html#msg542733 (https://forum.fhem.de/index.php/topic,62987.msg542733.html#msg542733)
Nun kann ich aber das fakelog aus der def nicht löschen weil der diese Fehlermeldung macht...
wrong syntax: define <name> FileLog filename regexp [readonly]
sobald ich fakelog rauslösche.
Zitat von: misux am 27 Dezember 2021, 14:17:06
Hier her habe ich das mir dem fakelog... dachte das wäre in Ordnung...
https://forum.fhem.de/index.php/topic,62987.msg542733.html#msg542733 (https://forum.fhem.de/index.php/topic,62987.msg542733.html#msg542733)
Nun kann ich aber das fakelog aus der def nicht löschen weil der diese Fehlermeldung macht...
wrong syntax: define <name> FileLog filename regexp [readonly]
sobald ich fakelog rauslösche.
Hallo Misux,
schau bitte auch mal nach, ob es etwas mit dem DbLog zutun hat, war Du für die Plenticore Devices eingerichtet hast.
Ich weiß nicht, ob es da eventuell jetzt eine Wechselwirkung gibt, wenn es das Attribut
DbLogExclude .*
im Device gibt.
VG
Christian
define Logfile FileLog ./log/fhem-%Y-%m.log Logfile
tausche doch einmal fakelog gegen Logfile, so wird es aktuell ausgeliefert
Edit
ein set Logfile reopen
braucht auch noch
Das Attribute global logfile ist falsch, fakelog hat dort nichts zu suchen!!!
Es muss so aussehen.
attr global logfile ./log/fhem-%Y-%m-%d.log
Logfile ist eigentlich ok, ja wird jetzt anders ausgeliefert. Muss ich mir mal klar machen warum ...
Zitat von: Otto123 am 27 Dezember 2021, 20:42:57
Das Attribute ist falsch
attr global logfile ./log/fhem-%Y-%m-%d.log
fakelog hat dort nichts zu suchen!!!
Ja das stimmt, solange dort fakelog steht wird auch kein Log geschrieben, aber sobald man es wieder rausnimmt gehts wieder weiter (ohne restart) und das scheint bei Misux ja nicht so zu sein, dafür muss es ja auch eine Erklärung geben ?
@TomLee er versucht doch Logfile zu ändern und nicht das attr global?
In global stand aber mal fakelog bei ihm drin :
ZitatHabe jetzt im global das fakelog gelöscht... aber im Logfile in der DEF lässt er mich das nicht löschen...
Bei mir steht (jetzt stand, weil das offensichtlich nicht mehr nötig ist) auch fakelog im Device Logfile, das war mal nötig soweit ich mich erinnere das in der setter-Auswahlliste clear zur Verfügung stand, dazu (so hab ichs in Erinnerung) durfte <readonly> kein Device matchen (fakelog ist also eigentlich nur ein regexp der auf nix matchen sollte).
Ich wollte bloss anmerken das ich bei mir nachvollziehen konnte das kein Log mehr geschrieben wird wenn man fakelog in global ergänzt (wo nur der Name stehen sollte) und das es (bei mir) wieder weiter geht wenn man es wieder entfernt, ohne restart oder reopen und egal ob mit fakelog oder Logfile in readonly.
ok danke - überlesen ::)
mit der DEF ./log/fhem-%Y-%m.log Logfile
gibt es ein set Logfile clear
und das Reading linesInTheFile fehlt
mit der DEF ./log/fhem-%Y-%m.log fakelog
gibt es kein set
und das Reading linesInTheFile steht immer auf 0
ok, habe jetzt im "Logfile" anstatt fakelog Logfile drin stehen und habe Logfie clear durchgeführt.
Im global konnte ich im attribut "logfile" das fakelog löschen.
Werde es nun beobachten. aber es scheint schon was bewirkt zu haben denn seit set clear steht jedenfalls schon dieser eintrag im Logfile!
Guten Tag allerseits!
Ich habe seit kurzem genau das selbe Problem, dass das globale Logfile nicht mehr beschrieben wird.
Der Auslöser war bei mir, dasss ich das Zeitmuster des Dateinamens des Logile neu definiert hatte, von -%Y-%W auf -Y-%m-%d.
Seitdem tut sich nichts mehr, auch dann nicht, als ich den -früher üblichen- Ausdruck fakelog in Logfile geändert habe.
list Logfile zeigt:
Internals:
DEF ./log/fhem-%Y-%m-%d.log Logfile
FD 6
FUUID 5e18c03e-f33f-8be1-b759-1a16b1b3956b80b5
NAME Logfile
NOTIFYDEV Logfile
NR 16
NTFY_ORDER 50-Logfile
REGEXP Logfile
STATE active
TYPE FileLog
currentlogfile ./log/fhem-2022-03-27.log
logfile ./log/fhem-%Y-%m-%d.log
READINGS:
2022-03-27 00:00:01 linesInTheFile 0
Attributes:
nrarchive 3
Zitat von: DocCyber am 27 März 2022, 12:57:51
Internals:
DEF ./log/fhem-%Y-%m-%d.log Logfile
Wundert mich nicht. Was soll denn bei diesem Regexp auch gelogged werden?
Da ist das Regexp mit verloren gegangen....Das sollte z.B. so aussehen:
Also der Eintrag:
attr global logfile ./log/fhem-%Y-%m.log
Und die Definition
defmod Logfile FileLog ./log/fhem-%Y-%m.log fakelog
Oder "neuerdings"
defmod Logfile FileLog ./log/fhem-%Y-%m.log Logfile
gehören quasi zusammen ;)
Und ich hatte es auch schon, dass nach Änderungen und Manipulationen des Logfiles der Zustand auftritt, dass ohne Fehlermeldung nicht mehr geloggt wird. Da hilft shutdown restart :)
Zitat von: Nobbynews am 27 März 2022, 13:30:26
Wundert mich nicht. Was soll denn bei diesem Regexp auch gelogged werden?
Deine Antwort trifft zu für Devices, aber nicht für das globale Logfile, das ich hier meine. ;)
Sieh dir doch mal den restlichen Thread an...
Zitat von: Otto123 am 27 März 2022, 14:09:45
Da hilft shutdown restart :)
Leider nicht - jedenfalls nicht bei mir. :( Hab's gerade noch mal -vermutlich schon zum 10. Mal- versucht.
2022.03.27 15:03:49 0: Server shutdown
Mehr steht im Logfile nicht drin.
Hat da hat einer die Datei im Zugriff? Geöffnet an andere Stelle?
Kann man ev. so anzeigen?
sudo lsof +D /opt/fhem/log/
@otto123: Hast du dich vertippt? ???
RPi3:~ $ sudo lsof +D /opt/fhem/log/
sudo: lsof: Befehl nicht gefunden
RPi3:~ $
EDIT: Sieht so aus, als gäbe es lsof bei meinem Raspberry nicht. Merkwürdig.
EDIT 2: Ich würde ja am liebsten mal ein Update machen, aber ich habe die Befürchtung, dass meine FTUI-Oberfläche danach nicht mehr funktioniert. Kann man das Update von FTUISRV ausschließen, ohne dass der Rest beeinflusst wird?
ja der Befehl kommt mit irgendeinem debian Paket, bei mir ist er auch nicht auf allen Systemen vorrätig :) https://packages.debian.org/search?keywords=lsof
Zitat von: Otto123 am 27 März 2022, 16:24:58
ja der Befehl kommt mit irgendeinem debian Paket, bei mir ist er auch nicht auf allen Systemen vorrätig :) https://packages.debian.org/search?keywords=lsof
Ich bekomme es nicht hin, dieses Paket zu installieren. Müsste irgendwie mit
apt-get gehen, denke ich.
Zitat von: Otto123 am 27 März 2022, 15:45:01
Hat da hat einer die Datei im Zugriff? Geöffnet an andere Stelle?
Kann man ev. so anzeigen?
sudo lsof +D /opt/fhem/log/
Aber unabhängig davon kann es doch nicht sein, dass die Datei anderweitig in Beschlag genommen wurde, denn sonst könnte doch auch nicht der Eintrag
2022.03.27 15:03:49 0: Server shutdown
geschrieben werden. Oder stehe ich mal wieder auf dem Schlauch?
Ich habe versuchsweise mal verbose auf 4 gesetzt, aber nach wie vor wird nichts ins Logfile reingeschrieben.
Überhaupt scheint generell der Wurm drin zu sein:
Ich würde gern ein Update machen und zuvor ein
Backup durchführen, aber auch das startet nicht:
Der Befehl
backup wird zwar ordnungsgemäß quittiert, aber dabei wird auf das Logfile verwiesen. ::)
Started the backup in the background, watch the log for details
Unmittelbar danach, praktisch zeitgleich, steht im Event-Monitor
2022-03-27 16:53:54 Global global backup done
Überflüssig zu erwähnen, dass im Backupverzeichnis natürlich nichts steht. >:(
list global
Internals:
DEF no definition
FD 3
NAME global
NR 1
STATE no definition
TYPE Global
currentlogfile ./log/fhem-2022-12.log
logfile ./log/fhem-%Y-%W.log
Attributes:
autoload_undefined_devices 1
autosave 0
backupdir /mnt/nas/raspberry/fhem/backups
configfile fhem.cfg
logfile ./log/fhem-%Y-%W.log
modpath .
nrarchive 3
room 00_SYSTEM
sendStatistics onUpdate
statefile ./log/fhem.save
updateInBackground 1
userattr cmdIcon devStateIcon devStateIcon:textField-long devStateStyle icon sortby webCmd webCmdLabel:textField-long widgetOverride
verbose 4
version fhem.pl:21333/2020-03-01
Hat noch jemand eine Idee?
EDIT:
Gerade fällt mir auf, dass unter den obigen Attributen noch
currentlogfile ./log/fhem-2022-12.log steht.
Wie kann das sein, wo ich doch ganz aktuell
./log/fhem-%Y-%m-%d.log Logfile festgelegt habe? :o
Platte voll? In FHEM
{qx(df -h)}
Oder in der Console
df -h
Zitat von: DocCyber am 27 März 2022, 18:37:08
Wie kann das sein, wo ich doch ganz aktuell ./log/fhem-%Y-%m-%d.log Logfile festgelegt habe? :o
Hast Du nicht!
list global
Zitatlogfile ./log/fhem-%Y-%W.log
Ist der backup Pfad denn gemounted und erreichbar?
Zitatbackupdir /mnt/nas/raspberry/fhem/backups
Die Platte ist ordnungsgemäß unter /mnt/nas eingebunden und keinesfalls voll:
{qx(df -h)} ergibt
Dateisystem Größe Benutzt Verf. Verw% Eingehängt auf
/dev/root 15G 2,4G 12G 17% /
devtmpfs 430M 0 430M 0% /dev
tmpfs 462M 0 462M 0% /dev/shm
tmpfs 462M 6,2M 456M 2% /run
tmpfs 5,0M 4,0K 5,0M 1% /run/lock
tmpfs 462M 0 462M 0% /sys/fs/cgroup
/dev/mmcblk0p1 253M 49M 204M 20% /boot
//192.168.178.1/nas/WD-5000BEVExternal-01 467G 361M 466G 1% /mnt/nas
tmpfs 93M 0 93M 0% /run/user/1000
Könnte es sein, dass das Backup-Zielverzeichnis /mnt/nas/raspberry/fhem/backups beim durch fhem nicht beschreibbar ist?
Was ich nicht verstehe: Wenn ich das (globale) Logfile öffne, kommt eine leere Datei.
list Logfile ergibt:
Internals:
DEF ./log/fhem-%Y-%m-%d.log Logfile
FD 6
FUUID 5e18c03e-f33f-8be1-b759-1a16b1b3956b80b5
NAME Logfile
NOTIFYDEV Logfile
NR 16
NTFY_ORDER 50-Logfile
REGEXP Logfile
STATE active
TYPE FileLog
currentlogfile ./log/fhem-2022-03-29.log
logfile ./log/fhem-%Y-%m-%d.log
READINGS:
2022-03-29 00:00:01 linesInTheFile 0
Attributes:
nrarchive 3
aber list global ergibt:
Internals:
DEF no definition
FD 3
NAME global
NR 1
STATE no definition
TYPE Global
currentlogfile ./log/fhem-2022-13.log
logfile ./log/fhem-%Y-%W.log
Attributes:
autoload_undefined_devices 1
autosave 0
backupdir /mnt/nas/raspberry/fhem/backups
configfile fhem.cfg
logfile ./log/fhem-%Y-%W.log
modpath .
nrarchive 3
sendStatistics onUpdate
statefile ./log/fhem.save
updateInBackground 1
userattr cmdIcon devStateIcon devStateIcon:textField-long devStateStyle icon sortby webCmd webCmdLabel:textField-long widgetOverride
verbose 4
version fhem.pl:21333/2020-03-01
Ich war der Meinung, dass die logfile-Definition in global eine Standardvorgabe ist. ???
schau mal, meine Anmerkung in #15 hast Du irgendwie ausgeblendet :o
Dein global und Dein Logfile passen nicht zusammen. Mach dies
attr global logfile ./log/fhem-%Y-%m-%d.log
ZitatKönnte es sein, dass das Backup-Zielverzeichnis /mnt/nas/raspberry/fhem/backups beim durch fhem nicht beschreibbar ist?
Klar kann das sein. Was passiert bei einem
{qx(touch /mnt/nas/raspberry/fhem/backups/willi.txt)}
Und was sagt ein
{qx(ls -lha /mnt/nas/raspberry/fhem/backups)}
Ich würde mal die Kompletten Berechtigungen auf Filesystemebene prüfen ...
ls -lha /opt/fhem
Noch ein paar Anmerkungen:
- Du kannst das Zielverzeichnis fürs Backup auch direkt im FHEM-Ordner mounten. Du mußt es nicht "extern" unter /mnt machen.
- Wenn Du es unbedingt woanders willst, kannst Du auch mit einem Symlink im FHEM-Ordner aufs Ziel zeigen. z.B. backup
Fürs 2. als Beispiel (ungetestet) für Dich, eventuell vorher den Backup-Ordner "löschen" oder wegmoven
ln -s /mnt/nas/raspberry/fhem/backups /opt/fhem/backup
Zitat von: Otto123 am 29 März 2022, 20:42:06
schau mal, meine Anmerkung in #15 hast Du irgendwie ausgeblendet :o
stimmt - habe ich überlesen.
Klar kann das sein. Was passiert bei einem
{qx(touch /mnt/nas/raspberry/fhem/backups/willi.txt)}
Es passiert ... nichts. Keine Fehlermeldung, aber es wird auch kein File im Zielpfad erzeugt.
{qx(ls -lha /mnt/nas/raspberry/fhem/backups)}
insgesamt 0
drwxr-xr-x 2 pi pi 0 Mär 27 19:27 .
drwxr-xr-x 2 pi pi 0 Mär 27 16:33 ..Folgendes funktioniert, aber nur als pi,
nicht als fhem (Speichern: kein Berechtigung):
nano /mnt/nas/raspberry/fhem/backups/test2.txt
Man müsste also der Gruppe
nasusers Schreibrechte einräumen für
/mnt/nas/raspberry (und Unterverzeichnisse) - Ich habe das probiert, aber bislang noch erfolglos.
Zitat von: Wernieman am 29 März 2022, 21:17:26
Ich würde mal die Kompletten Berechtigungen auf Filesystemebene prüfen ...
{qx(ls -lha /opt/fhem)}
insgesamt 1,7M
drwxr-xr-x 14 fhem dialout 4,0K Mär 29 19:11 .
drwxr-xr-x 4 root root 4,0K Mär 17 13:57 ..
drwxr-xr-x 2 fhem dialout 4,0K Mär 25 23:15 backup
-rw------- 1 fhem dialout 53 Mär 29 19:11 .bash_history
-rw-r--r-- 1 fhem dialout 321K Mär 18 15:09 CHANGED
-rw-r--r-- 1 fhem dialout 40K Mär 18 15:09 configDB.pm
drwxr-xr-x 54 fhem dialout 4,0K Mär 18 15:09 contrib
drwxr-xr-x 3 fhem dialout 4,0K Mär 17 13:57 demolog
drwxr-xr-x 4 fhem dialout 4,0K Mär 18 15:09 docs
drwxr-xr-x 6 fhem dialout 32K Mär 18 15:09 FHEM
-rw-r--r-- 1 fhem dialout 146K Mär 30 11:13 fhem.cfg
-rw-r--r-- 1 fhem dialout 25K Nov 7 14:48 fhem.cfg.demo
-rwxr-xr-x 1 fhem dialout 157K Mär 18 15:09 fhem.pl
drwx------ 3 fhem dialout 4,0K Mär 17 14:04 .gnupg
drwxr-xr-x 3 fhem dialout 4,0K Mär 17 13:57 lib
drwxr-xr-x 3 fhem dialout 4,0K Mär 29 19:09 .local
drwxr-xr-x 2 fhem dialout 80K Mär 30 00:00 log
-rw-r--r-- 1 fhem dialout 42K Mär 18 15:09 MAINTAINER.txt
-rw-r--r-- 1 fhem dialout 935 Nov 7 14:48 README_DEMO.txt
-rw-r--r-- 1 fhem dialout 820K Mär 18 15:09 regSave.cfg
drwxr-xr-x 7 fhem dialout 4,0K Mär 18 15:09 restoreDir
drwxr-xr-x 2 fhem dialout 4,0K Mär 18 15:10 unused
drwxr-xr-x 11 fhem dialout 4,0K Mär 18 10:15 wwwZitat
Du kannst das Zielverzeichnis fürs Backup auch direkt im FHEM-Ordner mounten. Du mußt es nicht "extern" unter /mnt machen.
Ausnahmsweise mal etwas, das mir klar war. :)
Naja dann ist /mnt/nas/raspberry/fhem/backups quasi "falsch" gemountet. pi hat Rechte alle anderen keine.
Hilfe dazu hängt jetzt davon ab wie das gemountet ist?
Ich bin ja immer der Ansicht: mounte dann wenn Du es brauchst, als der user der das Laufwerk braucht :)
Naja ... wenn ich als user pi das NAS selber brauche, kann ich das ja manuell machen - ist ja kein Aufwand.
Aber, und so ist der Plan, wenn fhem das Backup automatisch täglich machen soll, müsste fhem vorher auch automatisch mounten können.
dem steht ja nichts im Wege. User fhem kann doch auch "automatisch" mounten. Einfacher Ablauf:
mount (dabei Prüfung ob das funktioniert hat, das Laufwerk verfügbar ist)
backup
unmount
Wie ist es denn nun gemountet?
@Otto: A la...
#!/bin/bash
mount|grep nas 2>/dev/null
if [ "$?" -eq 1 ]; then
mount -t cifs -o username=<user,password=<pw> //<ziel> /mnt/nas
sleep 10
fi
[backup]
umount -lv /mnt/nas
??
Grüße
Hallo alanblack,
ich sage mal nein, weil der "spontane" mount Befehl in deinem Beispiel funktioniert mMn nur als root / sudo - das muss nicht sein.
Es sollte besser über die fstab geschehen!
Ich verwende ein Script in der Art:
#!/bin/bash
url='8083'
qpath=$1
dpath=$2
LOG=./backupFhem.log
# check if fhemcl exists
file="fhemcl.sh"
fhemcl="./$file"
if [ ! -e $fhemcl ]
then
echo "$file is missing"
wget -O $fhemcl https://raw.githubusercontent.com/heinz-otto/fhemcl/master/$file
chmod +x $fhemcl
fi
#
{
date
# mount, sync
if mount "$dpath"
then
# only piping works inside crontab
echo "set BackupFhem gestartet"|$fhemcl $url
if rsync -rut ${qpath}/backup ${qpath}/restoreDir ${dpath}/fhem/$(hostname)
then
echo "set BackupFhem gesichert"|$fhemcl $url
else
echo "set BackupFhem RsyncError"|$fhemcl $url
fi
umount "$dpath"
else
echo "set BackupFhem MountError"|$fhemcl $url
fi
} >> $LOG 2>&1
Der Aufruf erfolgt z.B. mit dem FHEM Befehl "bash backupFhem.sh . /mnt/Sicherung"
Das Skript läuft nicht blockierend und meldet Zustände an FHEM. Ich mache vorher FHEM backup lokal und schreibe die Sicherungsdateien auf den Server weg - quasi indirekt. Kann man aber auch direkt mit FHEM backup machen.
Gruß Otto
Zitat von: Otto123 am 30 März 2022, 23:58:43
Hallo alanblack,
ich sage mal nein, weil der "spontane" mount Befehl in deinem Beispiel funktioniert mMn nur als root / sudo - das muss nicht sein.
Es sollte besser über die fstab geschehen!
Ich verwende ein Script in der Art:
[...]
Der Aufruf erfolgt z.B. mit dem FHEM Befehl "bash backupFhem.sh . /mnt/Sicherung"
Da ich dieses Skript über cron laufen lasse, habe ich kein Problem mit sudo. Zudem sichere ich
zu FHEM gleich noch anderes weg, was als User fhem nicht ginge.
Den mount mache ich nicht über fstab, weil ich dann nicht dauerhaft eine aktive Verbindung
zum Sicherungserver aufrecht erhalten muss, die mMn eine unnötige Sicherheitslücke
darstellt.
Und wenn fhem aus welchen Gründen auch immer nicht läuft, habe ich trotzdem ein Backup.
Grüße
Zitat von: alanblack am 31 März 2022, 07:16:30
Den mount mache ich nicht über fstab, weil ich dann nicht dauerhaft eine aktive Verbindung
zum Sicherungserver aufrecht erhalten muss, die mMn eine unnötige Sicherheitslücke
darstellt.
Moin,
der mount an sich, wird ja nicht durch bloßen Eintrag in die fstab ausgeführt, da irrst Du. Durch einen entsprechenden Eintrag in der fstab wird noch nicht gemounted. Wie das funktioniert hatte ich hier (https://heinz-otto.blogspot.com/2018/02/windows-server-freigabe-auf-dem.html)mal aufgeschrieben.
Dein Sicherheitsproblem ist: das jetzt die Konto Daten direkt script stehen ;). Das pflegt sich schlecht :) und führt meist zu nachlässigem Umgang.
Wie Du in meinem Script siehst, wird der mount im Script ausgeführt, in der fstab steht nur wie es geht. ;) Ich halte auch nichts von einer ständigen Verbindung zum Sicherungsserver.
Gruß Otto
Ich habe bei mir auch ein mount im Backup, allerdings sind das auch USB-Platten. Da es verschiedene sind, konnte ich nichts in fstab eintragen.
Auf jedem Falle sollte man aber nach dem mount den "Fehler-Code" Abfragen. Es kann immer zu Problemen kommen (Warum auch immer).
Wenn Du es per CRON-Job startest, warum dann mit User fhem?
Zitat von: Otto123 am 27 März 2022, 14:09:45
Also der Eintrag:
attr global logfile ./log/fhem-%Y-%m.log
und die Definition
defmod Logfile FileLog ./log/fhem-%Y-%m.log Logfile
gehören quasi zusammen ;)
Ich hatte deinen Hinweis zunächst überlesen, aber es nun so geändert, so wie du es beschrieben hattest.
Jetzt funktioniert auch das Schreiben ins (globale) Logfile wieder. :)
Aber wieso muss man in diesem Fall an
zwei Stellen ändern? Ist doch sonst in
fhem nirgendwo üblich. ???
Danke für deine Hilfe, @otto123 :)