[Gelöst] minidlna.log permission denied nach Upgrade von Debian 10 auf 11

[buhtz]

Ich nutze schon seit ewigen Zeiten minidlna; vermutlich schon seit Debian 9. Wie genau der konfiguriert war, weiß ich aus dem Kopf echt nicht mehr. Siehe weiter unten. Ich weiß nur, es sind 4 Instanzen, die mit so einer systemd-template-Zaubertechnik deren Fachbegriff ich nicht kenne gleichzeitig gestartet werden. Erkläre ich weiter unten genauer.

Die gezeigte Fehlermeldung ist bei allen 4 Instanzen die gleiche.

Nachdem ich ein Upgrade von Debian 10 auf Debian 11 (in sources.list "buster" auf "bullseye" geändert) habe, startet minidlna nicht mehr. Das log ist ziemlich eindeutig:

Code: Alles auswählen

-- Boot d01a70c19cfb4a62b9e91a5d8879b10f --
Aug 18 20:28:50 OLAF systemd[1]: Started Mediaserver minidlna: Christian.
Aug 18 20:28:50 OLAF minidlnad[665]: minidlna.c:1028: fatal: Failed to open log file '/var/log/minidlna.d/minidlna.log': Permission denied
Aug 18 20:28:50 OLAF systemd[1]: minidlna@Christian.service: Main process exited, code=exited, status=255/EXCEPTION
Aug 18 20:28:50 OLAF systemd[1]: minidlna@Christian.service: Failed with result 'exit-code'.
...restarts...
Aug 18 20:28:52 OLAF systemd[1]: minidlna@Christian.service: Scheduled restart job, restart counter is at 5.
Aug 18 20:28:52 OLAF systemd[1]: Stopped Mediaserver minidlna: Christian.
Aug 18 20:28:52 OLAF systemd[1]: minidlna@Christian.service: Start request repeated too quickly.
Aug 18 20:28:52 OLAF systemd[1]: minidlna@Christian.service: Failed with result 'exit-code'.
Aug 18 20:28:52 OLAF systemd[1]: Failed to start Mediaserver minidlna: Christian.

OK, die Rechte sehen so aus

Code: Alles auswählen

drwxr-xr-x 2 root root 4,0K  7. Apr 2021  /var/log/minidlna.d/

Nun weiß ich nicht, ob sich etwas an den Rechten und Gruppenzugehörigkeiten geändert hat, oder ob in meiner ursprünglichen minidlna config dieser gar nicht in das besagte Verzeichnis schreiben würde.

Die aktuelle Konfiguraiton

Im Ordner /etc/minidlna.d liegen vier *.conf Dateien; für jede Instanz eine. Hier die Christian.conf

Code: Alles auswählen

media_dir=A,/Daten/Backup/.backintime/backintime/TONNE/user/Musik_SSH/last_snapshot/backup/home/user/Musik/_MUSIC
db_dir=/var/cache/minidlna.d/Christian
log_dir=/var/log/minidlna.d
#root_container=M
port=8204
friendly_name=Christian
inotify=yes
album_art_names=Cover.jpg/cover.jpg/AlbumArtSmall.jpg/albumartsmall.jpg
album_art_names=AlbumArt.jpg/albumart.jpg/Album.jpg/album.jpg
album_art_names=Folder.jpg/folder.jpg/Thumb.jpg/thumb.jpg
uuid=4cf13cf2-b785-41ba-9aa6-8383278d642b
model_name=
model_number=

Dann gibt es in /etc/systemd/system/ ein paar spannende Sachen. Für jede der vier Instanzen gibt es einen Ordner der Art minidlna@Christian.service.d und darin jeweils eine service.conf mit folgenden Inhalt (der vermutlich sagt, mit welchen Rechten der Service/die Unit laufen soll?):

Code: Alles auswählen

[Service]
User=backup
Group=backup

Dann gibt es den Ordner /etc/systemd/system/minidlna.target.wants der eigentlich nur vier Symlinks dieser Art enthält, die alle auf das selbe Ziel zeigen:

Code: Alles auswählen

insgesamt 0
lrwxrwxrwx 1 root root 37  7. Apr 2021  minidlna@Christian.service -> /etc/systemd/system/minidlna@.service

Dann gibt es da noch minidlna.target:

Code: Alles auswählen

[Unit]
Description=minidlna DLNA-Servers
PartOf=network-online.target

#StopWhenUnneeded=yes

[Install]
WantedBy=network-online.target

und minidlna@.service

Code: Alles auswählen

[Unit]
Description=Mediaserver minidlna: %i
ConditionPathExists=/etc/minidlna.d/%i.conf
PartOf=minidlna.target
ReloadPropagatedFrom=minidlna.target

[Service]
RuntimeDirectory=minidlna-%i
ExecStart=/usr/sbin/minidlnad -S -f /etc/minidlna.d/%i.conf -P %t/minidlna-%i/minidlna-%i.pid
Restart=always
KillMode=mixed

[Install]
WantedBy=minidlna.target
DefaultInstance=%H

Puh...

Nun würde ich ins Blaue überlegen, dass ich vermutlich die Besitzrechte des besagten log-Ordners einfach ändern sollte und gut ist.

EDIT: Nun habe ich die Rechte von /var/log/minidlna.d einfach mal radikal auf drwxrwxrwx geändert. Die permission denied Meldung erscheint dennoch; natürlich auch nach Neustart. Alllerdings nicht für alle vier Instanzen, sondern nur drei. Denn eine der Instanzen schreibt dort jetzt ein Log-file.

Die conf-Dateien der vier Instanzen zeigen alle auf das Selbe Verzeichnis. Jeder sollte aber eine eigene Log-Datei schreiben. Ich sehe das aber nicht in der Config und wundere mich, warum das vorher bei Debian 10 noch funktioniert hat.

[hikaru]

Dann gibt es in /etc/systemd/system/ ein paar spannende Sachen. Für jede der vier Instanzen gibt es einen Ordner der Art minidlna@Christian.service.d und darin jeweils eine service.conf mit folgenden Inhalt (der vermutlich sagt, mit welchen Rechten der Service/die Unit laufen soll?):

Code: Alles auswählen

[Service]
User=backup
Group=backup

Bist du sicher, dass die alle gleich sind? Standardmäßig sollte hier nämlich minidlna:minidlna stehen, nicht backup:backup. [1][2]

[1] https://sources.debian.org/src/minidlna ... a.service/
[2] https://sources.debian.org/src/minidlna ... a.service/

[JTH]

Ah, eine kleine Detektivarbeit zum damit verspäteten Start in den Tag

die mit so einer systemd-template-Zaubertechnik deren Fachbegriff ich nicht kenne

Die Services (und andere systemd-Units) mit @ im Namen heißen Template-Units. Man kann sie mit einem Namen hinter dem @ mehrfach instanziieren, wie du es hier mit Christian und anderen Namen gemacht hast.

der vermutlich sagt, mit welchen Rechten der Service/die Unit laufen soll?):

Code: Alles auswählen

[Service]
User=backup
Group=backup

Genau. Wie hikaru angemerkt hat, ist der Benutzer backup hier ein bisschen ungewöhnlich. Falls du eh für alle vier Instanzen denselben Benutzer benutzt (haha), könntest du den auch in der minidlna@.service direkt festlegen.

Dann gibt es den Ordner /etc/systemd/system/minidlna.target.wants der eigentlich nur vier Symlinks dieser Art enthält, die alle auf das selbe Ziel zeigen:

Die Symlinks sorgen für/sind die Instanziierung des Templates mit dem angegebenen Namen nach dem @.

Denn eine der Instanzen schreibt dort jetzt ein Log-file.

Das wird die Instanz sein, die als erstes voll gestartet war und damit die Logdatei öffnen konnte.

warum das vorher bei Debian 10 noch funktioniert hat.

Das ist anscheinend der Knackpunkt. In der Version von minidlna in Buster (und vermutlich auch vorher) wurde überhaupt keine Logdatei verwendet, wenn die Option -S benutzt wurde (das ist bei dir der Fall). Dann wurde einfach nach stdout geloggt.

In der minidlna-Version in/ab Bullseye hat sich der Code einigermaßen verändert. Im Original wird, wenn -S benutzt wird, zwar trotzdem weiterhin nicht in eine Logdatei geschrieben. Dummerweise wird der Code für das Debian-Paket aber (warum, hab ich nichts zu gefunden) gepatcht und nimmt dieses Verhalten raus. Das Logverzeichnis wird damit immer auf den Standardwert gesetzt. Den Namen der in dem Ordner angelegten Logdatei zu ändern, ist nicht möglich. Der ist hardcodiert.

Das ist einigermaßen unpraktisch, wenn man minidlna mehrfach starten will. Man kann wegen des merkwürdigen Patches nicht dafür sorgen, dass überhaupt keine Logdatei angelegt wird. Den Namen der Datei kann man auch nicht ändern. Einen individuellen Logpfad kann man auch nicht per Option beim Aufruf übergeben – dafür gibt es keine Option. (Wenn es die gäbe, könntest du das in dem Template-Service generisch übergeben.) Du müsstest hier also in den .conf in /etc/minidlna jeweils ein eigenes log_dir angeben, etwa /var/log/minidlna/Christian, /var/log/minidlna@Christian oder ähnliches.

Wenn du anderen mit ähnlichem Problem weiterhelfen willst, könntest du zusätzlich nochmal nachhaken, warum für das Debian-Paket dieser do-not-disable-logs-with-systemd.patch eingebaut wurde. Oder es sogar als Bug melden, dass man deswegen, wenn gleichzeitig die Option -S benutzt wird, eine Logdatei nicht mehr abstellen kann. – Gut, andersherum konnte man ohne diesen Patch mit -S nie eine Logdatei bekommen. Vielleicht wurde deshalb gepatcht. Andererseits scheint mir der Patch die -S-Option zur Hälfte unsinnig zu machen.

Hoffe, ich habe nichts übersehen und schreibe keinen Käse.

[buhtz]

Großartig, das hilft. Danke für die Detektivarbeit.

Im Detail versteh ich die Änderungen nicht, aber ich werde das mal als Bug-Report zur Diskussion stellen.
https://bugs.debian.org/cgi-bin/bugrepo ... ug=1018757