Logfile wird nicht mehr beschrieben..

[Otto123]

Also der Eintrag:

Code: [Auswählen]

attr global logfile ./log/fhem-%Y-%m.logUnd die Definition

Code: [Auswählen]

defmod Logfile FileLog ./log/fhem-%Y-%m.log fakelogOder "neuerdings"

Code: [Auswählen]

defmod Logfile FileLog ./log/fhem-%Y-%m.log Logfilegehö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

[DocCyber]

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...

[DocCyber]

Da hilft shutdown restart

Leider nicht - jedenfalls nicht bei mir.   Hab's gerade noch mal -vermutlich schon zum 10. Mal- versucht.

Code: [Auswählen]

2022.03.27 15:03:49 0:  Server shutdown
Mehr steht im Logfile nicht drin.

[Otto123]

Hat da hat einer die Datei im Zugriff? Geöffnet an andere Stelle?
Kann man ev. so anzeigen?

Code: [Auswählen]

sudo lsof +D /opt/fhem/log/

[DocCyber]

@otto123: Hast du dich vertippt? 

Code: [Auswählen]

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?

[Otto123]

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

[DocCyber]

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.

Hat da hat einer die Datei im Zugriff? Geöffnet an andere Stelle?
Kann man ev. so anzeigen?

Code: [Auswählen]

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

Code: [Auswählen]

2022.03.27 15:03:49 0:  Server shutdowngeschrieben 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. 

Code: [Auswählen]

Started the backup in the background, watch the log for details
Unmittelbar danach, praktisch zeitgleich, steht im Event-Monitor

Code: [Auswählen]

2022-03-27 16:53:54 Global global backup done
Überflüssig zu erwähnen, dass im Backupverzeichnis natürlich nichts steht. 

list global

Code: [Auswählen]

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? 

[Otto123]

Platte voll? In FHEM

Code: [Auswählen]

{qx(df -h)}Oder in der Console

Code: [Auswählen]

df -h

Wie kann das sein, wo ich doch ganz aktuell ./log/fhem-%Y-%m-%d.log Logfile festgelegt habe? 

Hast Du nicht!
list global

logfile    ./log/fhem-%Y-%W.log

Ist der backup Pfad denn gemounted und erreichbar?

backupdir  /mnt/nas/raspberry/fhem/backups

[DocCyber]

Die Platte ist ordnungsgemäß unter /mnt/nas eingebunden und keinesfalls voll:
{qx(df -h)} ergibt

Code: [Auswählen]

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:

Code: [Auswählen]

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:

Code: [Auswählen]

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. 

[Otto123]

schau mal, meine Anmerkung in #15 hast Du irgendwie ausgeblendet 
Dein global und Dein Logfile passen nicht zusammen. Mach dies

Code: [Auswählen]

attr global logfile ./log/fhem-%Y-%m-%d.log

Kö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

Code: [Auswählen]

{qx(touch /mnt/nas/raspberry/fhem/backups/willi.txt)} Und was sagt ein

Code: [Auswählen]

{qx(ls -lha /mnt/nas/raspberry/fhem/backups)}

[Wernieman]

Ich würde mal die Kompletten Berechtigungen auf Filesystemebene prüfen ...

Code: [Auswählen]

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

Code: [Auswählen]

ln -s /mnt/nas/raspberry/fhem/backups /opt/fhem/backup

[DocCyber]

schau mal, meine Anmerkung in #15 hast Du irgendwie ausgeblendet 

stimmt - habe ich überlesen.

Klar kann das sein. Was passiert bei einem

Code: [Auswählen]

{qx(touch /mnt/nas/raspberry/fhem/backups/willi.txt)}Es passiert ... nichts. Keine Fehlermeldung, aber es wird auch kein File im Zielpfad erzeugt.

Code: [Auswählen]

{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):

Code: [Auswählen]

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.

[DocCyber]

Ich würde mal die Kompletten Berechtigungen auf Filesystemebene prüfen ...

Code: [Auswählen]

{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 www

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.   

[Otto123]

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

[DocCyber]

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.