[gelöst] zweite Instanz von MiniDLNA

[MoonKid]

Ich habe hier Jessie und möchte eine zweite MiniDLNA-Instanz laufen haben.

Ich habe einfach die /etc/init.d/minidlna nach /etc/init.d/minidlna2 kopiert und darin die Werte für die conf- und log-Datei geändert.
Dann habe ich natürlich auch /etc//minidlna.conf kopiert und angepasst (anderer Server-String und http-port).

Wie wird der gestartet?
sudo service minidlna2 start meldet nur, dass Unit minidlna2.service nicht vorhanden wäre.

Per [locate minidlna.service finde ich aber auch keine passende Datei für die erste Instanz (die aber läuft).

[smutbert]

systemd erzeugt erst beim Systemstart die sevice-Units aus den Startskripten in /etc/init.d - sieh mal ob »/var/run/systemd/generator.late/minidlna.service« existiert.
Ich weiß gar nicht wie systemd mit Startskripten umgeht, die mit dem alten init gar nicht gestartet würden, weil es keine Links in /etc/rc?.d gibt. (Aber das könntest du nachholen...)

Ich würde aber einfach versuchen auf diese automatisch erzeugten units zu verzichten und stattdessen selbst eine Unit schreiben und zwar für die erste Instanz in Form einer Datei »/etc/systemd/system/minidlna.service« mit dem Inhalt

Code: Alles auswählen

[Unit]
Description=minidlna server
After=network.target

[Service]
Type=simple
User=minidlna
Group=minidlna
ExecStart=/usr/bin/minidlnad -S
ProtectSystem=full
ProtectHome=on
PrivateDevices=on
NoNewPrivileges=on

[Install]
WantedBy=multi-user.target

(stammt aus dem arch-Paket [1], weil die bei arch was systemd angeht sehr auf Zack sind)
spätestens nach

Code: Alles auswählen

# systemctl daemon-reload
# systemctl enable minidlna.service

und einem Neustart sollte nun deine eigene service-Unit gestartet werden. Wenn das funktioniert kannst du einfach zusätzlich einge angepasste »/etc/systemd/system/minidlna2.service« erstellen und die auch aktivieren.

[1] https://www.archlinux.org/packages/comm ... /minidlna/

[MoonKid]

systemd erzeugt erst beim Systemstart die sevice-Units aus den Startskripten in /etc/init.d - sieh mal ob »/var/run/systemd/generator.late/minidlna.service« existiert.

Es existiert nirgends eine minidlna.service. Wenn systemd die units beim Start erzeugt, kann man irgendwo den Code der unit sehen ( so ähnlich wie das, was du von arch gepostet hast)? Wie gesagt, existiert die Datei nicht, auch wenn der Server läuft.

[smutbert]

Also wenn du jessie verwendest und das init-System nicht ausgetauscht hast, muss es so eine service-Unit geben. Mit

Code: Alles auswählen

# systemctl status minidlna.service

sollte er nicht nur anzeigen, dass dieser Dienst aktiv ist sondern auch den Pfad der .service-Datei ausgeben.

minidlna hab ich auf dem PC grad keines, aber dafür sieht man es hier am Beispiel des automatisch erzeugten swap-Targets:

Code: Alles auswählen

$ systemctl status swap.target
● swap.target - Swap
   Loaded: loaded (/lib/systemd/system/swap.target; static; vendor preset: enabled)
   Active: active since Mon 2017-02-06 09:00:47 CET; 2min 28s ago
     Docs: man:systemd.special(7)

Feb 06 09:00:47 achill systemd[1]: Reached target Swap.

[MoonKid]

Bei mir sieht das so aus

Code: Alles auswählen

● minidlna.service - LSB: Start minidlna at boot time
   Loaded: loaded (/etc/init.d/minidlna)
   Active: active (running) since Mi 2017-02-08 09:36:09 CET; 36min ago
  Process: 472 ExecStart=/etc/init.d/minidlna start (code=exited, status=0/SUCCESS)
   CGroup: /system.slice/minidlna.service
           └─522 /usr/bin/minidlnad -f /etc/minidlna.conf -P /run/minidlna/minidlna.pid

Kein target- und kein service--File. Auch die angezeigte /system.slice/minidlna.service existiert nicht.

Weiß also immer noch nicht, wie ich diesen Dienst duplizieren soll. Mir scheint es wäre am sinnvollsten /etc/init.d/minidlna zu duplizieren und anzupassen.
Allerdings würde mich mal dringend interessieren, wie die systemd-Enwickler sich das gedacht haben? Was wäre den der "Dienstweg", um Dienste zu duplizieren?

Versuch:
Also hab das jetzt probiert.

Code: Alles auswählen

$ systemctl status minidlna
● minidlna.service - LSB: Start minidlna at boot time
   Loaded: loaded (/etc/init.d/minidlna)
   Active: active (running) since Mi 2017-02-08 09:36:09 CET; 44min ago
  Process: 472 ExecStart=/etc/init.d/minidlna start (code=exited, status=0/SUCCESS)
   CGroup: /system.slice/minidlna.service
           └─522 /usr/bin/minidlnad -f /etc/minidlna.conf -P /run/minidlna/minidlna.pid

$ systemctl status minidlna2
● minidlna2.service - LSB: Start minidlna at boot time
   Loaded: loaded (/etc/init.d/minidlna2)
   Active: active (exited) since Mi 2017-02-08 10:20:28 CET; 40s ago
  Process: 738 ExecStart=/etc/init.d/minidlna2 start (code=exited, status=0/SUCCESS)

Warum wird der zweite Dienst gleich wieder beendet (falls ich das richtig interpretiere)?

Dass hab ich in der Datei duplkizierten Datei geändert.

Code: Alles auswählen

:/etc/init.d$ diff minidlna minidlna2
29c29
< NAME=minidlna
---
> NAME=minidlna2
55c55
< 	CONFIGFILE=/etc/minidlna.conf
---
> 	CONFIGFILE=/etc/minidlna2.conf
60c60
< 	LOGFILE=/var/log/minidlna.log
---
> 	LOGFILE=/var/log/minidlna2.log

[smutbert]

stimmt unter jessie, war die Ausgabe noch nicht so informativ.

Abgesehen von der Möglichkeit einfach trotzdem wie beschrieben ein oder zwei Service-Units anzulegen (entweder nur für die zweite Instanz oder auch für die erste Instanz, damit das init-Skript überhaupt nicht mehr verwendet wird) funktioniert das mit der angepassten Kopie des init-Skript schon auch.

Du brauchst je eine angepasste Kopie des init-Skripts und der Konfigurationsdatei - in ersterem passt du nicht nur Logdatei, Konfigurationsdatei, etc, sondern auch im Header den Namen des Dienstes an, also aus

Code: Alles auswählen

#!/bin/sh
### BEGIN INIT INFO
# Provides:          minidlna
...

wird

Code: Alles auswählen

#!/bin/sh
### BEGIN INIT INFO
# Provides:          minidlna2
...

Dann fehlen nur mehr die symbolischen Links in den Runleveln damit das init-Skript von systemd auch als "aktiviert" erkannt wird, in der Annahme, dass die Kopie also »/etc/init.d/minidlna2« heißt

Code: Alles auswählen

# update-rc.d minidlna2 defaults

Wenn es keine Fehlermeldung gibt, sollten danach nicht nur für minidlna sondern auch für minidlna2 Links vorhanden sein

Code: Alles auswählen

$ ls -l /etc/rc?.d/* | grep minidlna
lrwxrwxrwx 1 root root  18 Jul 10  2015 /etc/rc0.d/K01minidlna -> ../init.d/minidlna
lrwxrwxrwx 1 root root  19 Feb  8 10:31 /etc/rc0.d/K01minidlna2 -> ../init.d/minidlna2
lrwxrwxrwx 1 root root  18 Jul 10  2015 /etc/rc1.d/K01minidlna -> ../init.d/minidlna
lrwxrwxrwx 1 root root  19 Feb  8 10:31 /etc/rc1.d/K01minidlna2 -> ../init.d/minidlna2
lrwxrwxrwx 1 root root  18 Jul 30  2015 /etc/rc2.d/S01minidlna -> ../init.d/minidlna
lrwxrwxrwx 1 root root  19 Feb  8 10:31 /etc/rc2.d/S01minidlna2 -> ../init.d/minidlna2
lrwxrwxrwx 1 root root  18 Jul 30  2015 /etc/rc3.d/S01minidlna -> ../init.d/minidlna
lrwxrwxrwx 1 root root  19 Feb  8 10:31 /etc/rc3.d/S01minidlna2 -> ../init.d/minidlna2
lrwxrwxrwx 1 root root  18 Jul 30  2015 /etc/rc4.d/S01minidlna -> ../init.d/minidlna
lrwxrwxrwx 1 root root  19 Feb  8 10:31 /etc/rc4.d/S01minidlna2 -> ../init.d/minidlna2
lrwxrwxrwx 1 root root  18 Jul 30  2015 /etc/rc5.d/S01minidlna -> ../init.d/minidlna
lrwxrwxrwx 1 root root  19 Feb  8 10:31 /etc/rc5.d/S01minidlna2 -> ../init.d/minidlna2
lrwxrwxrwx 1 root root  18 Jul 10  2015 /etc/rc6.d/K01minidlna -> ../init.d/minidlna
lrwxrwxrwx 1 root root  19 Feb  8 10:31 /etc/rc6.d/K01minidlna2 -> ../init.d/minidlna2

... und nach einem Neustart hat systemd die unit erstellt und aktiviert

Code: Alles auswählen

$ systemctl status minidlna2 
● minidlna2.service - LSB: minidlna server
   Loaded: loaded (/etc/init.d/minidlna2; generated; vendor preset: enabled)
   Active: active (running) since Wed 2017-02-08 10:32:54 CET; 8min ago
     Docs: man:systemd-sysv-generator(8)
  Process: 2734 ExecStart=/etc/init.d/minidlna2 start (code=exited, status=0/SUCCESS)
   CGroup: /system.slice/minidlna2.service
           └─2761 /usr/sbin/minidlnad -f /etc/minidlna2.conf -P /run/minidlna2/minidlna2.pid

Feb 08 10:32:54 helios systemd[1]: Starting LSB: minidlna server...
Feb 08 10:32:54 helios systemd[1]: Started LSB: minidlna server.

Eleganter (und imho einfacher) wäre es trotzdem für minidlna und minidlna2 eigene .service-Dateien in »/etc/systemd/system« anzulegen.

Wobei mir noch immer schleierhaft ist wo auf deinem System die automatisch erstellen Service-Units für die init-Skripte landen, denn bei dem jessie hier landen sie genau dort, wo ich sie vermutet habe:

Code: Alles auswählen

$ ls -l /var/run/systemd/generator.late/minidlna*
-rw-r--r-- 1 root root 611 Feb  8 10:32 /var/run/systemd/generator.late/minidlna.service
-rw-r--r-- 1 root root 614 Feb  8 10:32 /var/run/systemd/generator.late/minidlna2.service

(wie erwartet auf einem tmpfs, was zumindest erklärt wieso du sie mit locate nicht findest)

[MoonKid]

Offensichtlich habe ich das Grundkonzept von SystemD noch nicht begriffen. Aus meiner User-Sicht habe ich den Eindruck, dass jetzt das "alte" Init-System (/etc/rc*, usw) mit SystemD in Kombination läuft und es damit doppelt-kompliziert wird.

Code: Alles auswählen

#!/bin/sh
### BEGIN INIT INFO
# Provides:          minidlna
...

Also wer denkt sich den sowas aus (ernst gefragt!)? Das ist ne Kommentarzeile. Kenne keine andere Software (bitte um Voschläge), die in Kommentarzeilen nach Daten sucht. Das ist ein Bug. Da sollte mindestens im Eingangskommentar stehen, dass #-Zeilen eben nicht nur Kommentarzeilen sind. Ist das systemd-spezifisch? Darf ich mich da bei upstream jetzt austoben?

Code: Alles auswählen

# update-rc.d minidlna2 defaults

In Verbindung mit der obigen "Kommentarzeile" war eins der Dinge, die hier noch fehlten. Zusätzlich muss man noch /etc/default/minidlna duplizieren.

Code: Alles auswählen

-rw-r--r-- 1 root root 589 Apr 28  2014 /etc/default/minidlna
lrwxrwxrwx 1 root root  21 Feb  8 15:55 /etc/default/minidlna2 -> /etc/default/minidlna

Und den Pfad zur Datenbank in /etc/minidlna2.confändern.

Code: Alles auswählen

db_dir=/var/cache/minidlna2

Nach einem komplette Re-Boot sieht das dann so aus

Code: Alles auswählen

:~$ sudo service --status-all | grep mini
 [ + ]  minidlna
 [ + ]  minidlna2

:~$ sudo systemctl status minidlna
● minidlna.service - LSB: Start minidlna at boot time
   Loaded: loaded (/etc/init.d/minidlna)
   Active: active (running) since Mi 2017-02-08 19:11:10 CET; 1min 32s ago
  Process: 515 ExecStart=/etc/init.d/minidlna start (code=exited, status=0/SUCCESS)
   CGroup: /system.slice/minidlna.service
           └─549 /usr/bin/minidlnad -f /etc/minidlna.conf -P /run/minidlna/minidlna.pid

Feb 08 19:11:08 Vdebian systemd[1]: Starting LSB: Start minidlna at boot time...
Feb 08 19:11:10 Vdebian minidlna[515]: Starting DLNA/UPnP-AV media server : minidlna.
Feb 08 19:11:10 Vdebian systemd[1]: Started LSB: Start minidlna at boot time.

:~$ sudo systemctl status minidlna2
● minidlna2.service - LSB: Start minidlna at boot time
   Loaded: loaded (/etc/init.d/minidlna2)
   Active: active (running) since Mi 2017-02-08 19:11:10 CET; 1min 36s ago
  Process: 513 ExecStart=/etc/init.d/minidlna2 start (code=exited, status=0/SUCCESS)
   CGroup: /system.slice/minidlna2.service
           └─548 /usr/bin/minidlnad -f /etc/minidlna2.conf -P /run/minidlna2/minidlna2.pid

Feb 08 19:11:08 Vdebian systemd[1]: Starting LSB: Start minidlna at boot time...
Feb 08 19:11:10 Vdebian minidlna2[513]: Starting DLNA/UPnP-AV media server : minidlna2.
Feb 08 19:11:10 Vdebian systemd[1]: Started LSB: Start minidlna at boot time.

Meine Clients sehen aber nur den zweiten Service. Irgendwas scheint sich da zu überlagern.
Wenn ich den ersten Neustart (sudo service minidlna restart) verschwindet der zweite und der erste taucht wieder auf - bei den Clients. An der Ausgabe von systemctl status ändert sich aber nix.

Vielleicht eine Besonderheit von minidlna oder dem UPnP-Protokoll an sich?

Die Unterschiede der Config-Dateien sind marginal

Code: Alles auswählen

:~$ diff /etc/minidlna*
16c16
< media_dir=A,/media/Media/Music2
---
> media_dir=A,/media/Media/Music
19c19
< db_dir=/var/cache/minidlna2
---
> db_dir=/var/cache/minidlna
49c49
< root_container=.
---
> root_container=M
64c64
< port=8201
---
> port=8200
71c71
< friendly_name=Vdebian2
---
> friendly_name=Vdebian1

[owl102]

Kenne keine andere Software (bitte um Voschläge), die in Kommentarzeilen nach Daten sucht.

Shell (Shebang), Javadoc, Doxygen.

[smutbert]

Ok, der Reihe nach...

Offensichtlich habe ich das Grundkonzept von SystemD noch nicht begriffen. Aus meiner User-Sicht habe ich den Eindruck, dass jetzt das "alte" Init-System (/etc/rc*, usw) mit SystemD in Kombination läuft und es damit doppelt-kompliziert wird.

Nein bei dir läuft ein reinrassiges systemd, aber systemd erzeugt automatisch eigene Service-Units aus Startskripten für Dienste, die (noch) keine systemd-Unit mitbringen.
Ganz ähnlich wie systemd ganz automatisch mount-Units aus den Einträgen in der fstab generiert.

Für Startskripte erzeugt systemd aber nur units, wenn die init-Skripte im alten init-System aktiviert wären, wenn also in /etc/rc?.d die entsprechenden symbolischen Links zum Starten und Stoppen vorhanden sind und die habe ich im obigen Beitrag mittels update-rc.d erzeugt. was mich gleich zum nächsten Punkt bringt:

Also wer denkt sich den sowas aus (ernst gefragt!)? Das ist ne Kommentarzeile.[…]

Das hat sich nicht systemd ausgedacht, das ist Teil von der älteren LSB. Die Shebang ist ja auch nur ein Kommentar -betrachte es einfach als erweiterte Shebang für init-Skripte.

Viel kann ich dir ohne Nachzuschauen auch nicht sagen (und nachschauen kannst du selbst ), aber da steht zB der Name des Dienstes drin und es finden auch Abhängigkeiten zu anderen Diensten ihren Platz - damit hat selbst das alte init-System ohne fixe Reihenfolge sondern auf Abhängigkeiten basierend booten können.
update-rc.d wertet diesen Kommentarheader aus und verhindert, dass ein Dienst aktiviert wird (also die gewünschten Symlinks erstellt werden), wenn bereits ein Skript aktiviert ist, das einen Dienst desselben Namens bereitstellt → daher die Änderung im Kommentar zu minidlna2

[…]
Meine Clients sehen aber nur den zweiten Service. Irgendwas scheint sich da zu überlagern.
Wenn ich den ersten Neustart (sudo service minidlna restart) verschwindet der zweite und der erste taucht wieder auf - bei den Clients. An der Ausgabe von systemctl status ändert sich aber nix.
[…]

Dazu fällt mir allerdings nichts ein.

[MoonKid]

Danke smutbert für deine Erläuterungen. So kann ich das verstehen und nachvollziehen.

Zu den zwei MiniDLNAs fällt mir noch ein, dass ich auch schon mal zwei unterschiedliche UPnP-Server auf einer Maschine hatte, ohne dass die sich irgendwie gegenseitig stören würden. Denke daher, dass es kein UPnP-Ding ist.

[smutbert]

Vielleicht probiere ich das mit den zwei Instanzen auch noch einmal aus - bis jetzt habe ich ja nur überprüft ob ich es überhaupt 2 Mal starten kann, aber versprechen kann ich nichts.

[sbruder]

Mit Systemd geht das auch schöner als mit zwei units. Es gibt zum Beispiel den openvpn@.service. Dann kann ich sagen:

Code: Alles auswählen

systemctl start openvpn@server

und er liest die Konfig von /etc/openvpn/server.conf.
Die Unit sieht auch ganz einfach aus:

Code: Alles auswählen

[Unit]
Description=OpenVPN connection to %i
PartOf=openvpn.service
ReloadPropagatedFrom=openvpn.service

[Service]
ExecStart=/usr/sbin/openvpn --daemon ovpn-%i --status /run/openvpn/%i.status 10 --cd /etc/openvpn --config /etc/openvpn/%i.conf
[…]

Das PartOf und ReloadPropagatedFrom, machen systemd klar, dass alle openvpn@-Services teil von openvpn.service sind und diese bei einem reload/restart von openvpn.service auch berücksichtigt werden.
Das %i ist der eigentliche Platzhalter.
Ob das jetzt mit minidlna funktioniert, weiß ich nicht, aber ich finde das so schöner gelöst (wenn man schon systemd hat, darf man auch die Funktionen davon nutzen).

[smutbert]

Das Hauptproblem liegt noch darin 2 funktionierende minidlna-Instanzen zu starten und hier fällt mir nun auf, dass sich laut deinem Diff die uuid zwischen beiden Konfigurationsdateien nicht unterscheidet. Um aus dem anderen Thread zu zitieren, der dir ohnehin schon aufgefallen ist:

[…]
minidlna@b.conf: network_interface und inotiy sind in allen confs gleich, der Rest muss angepasst werden. (ganz wichtig uuid)

media_dir=/musik/30_musik/home-klaus-vdr
db_dir=/var/cache/minidlna@b
log_dir=/var/log/minidlna@b
network_interface=eth0
port=8300
friendly_name=miniD_VDR_KK@debt21
serial=830083008300
model_number=2
inotify=yes
uuid=2

Gruss

[MoonKid]

Mal ne Detailfrage zur Diagnose:

Code: Alles auswählen

$ sudo systemctl status minidlna
● minidlna.service - LSB: Start minidlna at boot time
   Loaded: loaded (/etc/init.d/minidlna)
   Active: active (exited) since Fr 2017-02-10 14:05:41 CET; 1min 58s ago
  Process: 948 ExecStop=/etc/init.d/minidlna stop (code=exited, status=0/SUCCESS)
  Process: 953 ExecStart=/etc/init.d/minidlna start (code=exited, status=0/SUCCESS)

Feb 10 14:05:41 Vdebian systemd[1]: Starting LSB: Start minidlna at boot time...
Feb 10 14:05:41 Vdebian minidlna[953]: Starting DLNA/UPnP-AV media server : minidlna.
Feb 10 14:05:41 Vdebian systemd[1]: Started LSB: Start minidlna at boot time.

$ sudo service --status-all | grep mini
 [ + ]  minidlna
 [ + ]  minidlna2

Was sagt mir das exited in der Klammer? Läuft der Job nun oder nicht? Laut service läuft er ja (+). Laut ps -A läuft aber nur ein minidlna.

[smutbert]

Das exited sagt, dass das startskript (/etc/init.d/minidlna(2)) sich beendet hat (na klar hat es das gemacht). Dass es läuft weiß systemd möglicherweise nur weil das initskript sich mit Exitstatus 0 beendet hat. Im Zweifelsfall überprüfst du es eben mit

Code: Alles auswählen

$ ps aux | grep minidlna

Neuere Versionen von systemd (gibt es auch in jessie in den backports) sind etwas auskunftsfreudiger und zeigen auch den eigentlichen daemon, hier unter jessie mit systemd aus den backports

Code: Alles auswählen

$ systemctl status minidlna
● minidlna.service - LSB: minidlna server
   Loaded: loaded (/etc/init.d/minidlna; generated; vendor preset: enabled)
   Active: active (running) since Fri 2017-02-10 10:37:14 CET; 3h 58min ago
     Docs: man:systemd-sysv-generator(8)
  Process: 2819 ExecStart=/etc/init.d/minidlna start (code=exited, status=0/SUCCESS)
   CGroup: /system.slice/minidlna.service
           └─2838 /usr/sbin/minidlnad -f /etc/minidlna.conf -P /run/minidlna/minidlna.pid

Feb 10 10:37:14 helios systemd[1]: Starting LSB: minidlna server...
Feb 10 10:37:14 helios systemd[1]: Started LSB: minidlna server.

da sieht man also, dass minidlna mit PID 2838 läuft.

Wenn wir aber endlich zwei Instanzen hinbekommen, würde ich vorschlagen, dass wir (du ) auch eine entsprechend systemd-unit schreibst, damit wir auf die init-Skripte verzichten können. Ob es nun 2 unit-Files sind, für jede Instanz eine, oder so wie sbruder es gezeigt hat eine einzige Datei, die die beiden Instanzen startet, finde ich dann im Grunde eher nebensächlich.

[MoonKid]

Das Hauptproblem liegt noch darin 2 funktionierende minidlna-Instanzen zu starten und hier fällt mir nun auf, dass sich laut deinem Diff die uuid zwischen beiden Konfigurationsdateien nicht unterscheidet. Um aus dem anderen Thread zu zitieren, der dir ohnehin schon aufgefallen ist:

Die uuid ist nirgends bei minidlna dokumentiert. IMO läuft der Deamon als User "minidlna".

Wenn wir aber endlich zwei Instanzen hinbekommen, würde ich vorschlagen, dass wir (du ) auch eine entsprechend systemd-unit schreibst, damit wir auf die init-Skripte verzichten können. Ob es nun 2 unit-Files sind, für jede Instanz eine, oder so wie sbruder es gezeigt hat eine einzige Datei, die die beiden Instanzen startet, finde ich dann im Grunde eher nebensächlich.

Vielleicht vertstehe ich etwas grundlegend falsch. Aber IMO würde ich mich mit einer eigenen Unit außerhalb des vorgegebenen Weges (dessen Sinnhaftigkeit sei mal dahingestellt) bewegen. Das würde den Prozess nur noch komplizierter machen als er ist. Das Problem der zwei Units halte ich übrigens auch bereits für gelöst. Die sind da und starten.

Das sich beide minidlna-Instanzen (irgendwie) überlagern, halte ich für ein minidlna-Problem unabhängig von der SystemD-Geschichte.

Nebenbei finde ich zu den log-files etwas Bemerkenswertes:
Per default nutzt minidlna /var/log sofern nicht anders eingestellt. Bei mir müsste default gelten. Die log-files beider Instanzen landen aber tatsächlich in /var/cache/minidlna/minidlna.log und /var/cache/minidlna2/minidlna.log. Ich kann auch beim Aufruf durch systemD nicht erkennen, dass hier ein anderes log-dir als Aufrufparameter mitübergeben werden würde.

Übrigens kann ich das Verhalten des Überlagerns auch auf Debian unstable mit manuell (ohne SystemD) gestarteten minidlna-Instanzen reproduzieren. Ein solcher manueller Start ist unter Jessie wegen eines Bugs nicht möglich.

[smutbert]

In der manpage von minidlna.conf ist die uuid dokumentiert (mir war allerdings nicht auf Anhieb klar, dass damit die User ID gemeint ist) und ich denke klak hätte es im anderen Thrad nicht so hervorgehoben, wenn es nicht wichtig wäre. Bei gleicher uuid sieht der Client laut dieser Diskussion
https://sourceforge.net/p/minidlna/disc ... /165ad1ec/
nur eine Instanz - also genau das Problem, das du hast,.

Also einfach einen Benutzer minidlna2 für die zweite Instanz anlegen?
Ganz blicke ich aber noch nicht durch

[…]
user Specify the user name of UID to run as. Beware that if you are using the init script to start minidlnad, then this option has no effect and you should set USER in /etc/default/minidlna instead.

uuid Specify UID to run as.
[…]

ob sich uuid auch nicht auswirkt, wenn man es mittels init-Skript startet (vermutlich ists dasselbe).


und was deine Bedenken angeht:
Eine (oder zwei) service-Units zu schreiben ist wesentlich simpler als ein zweites Initskript, das man dann - wie wir nun schon wissen - auch erst wieder auf die alte init-Art aktivieren muss und dass alles nur damit systemd daraus automatisch eine unnötig komplizierte unit generiert, die er in weiterer Folge startet.
Ich kann am erstellen einer eigenen systemd-unit auch nichts "unübliches" erkennen - wenn man unter jessie etwas gestartet haben will schreibt man eine systemd-Unit, so wie man früher ein init-Skript zu schreiben versucht hat.

Der Log-Verzeichnisname kommt wahrscheinlich vom Namen des Dienstes (also das minidlna2 im Kommentar des init-Skriptes)

[MoonKid]

Der Log-Verzeichnisname kommt wahrscheinlich vom Namen des Dienstes (also das minidlna2 im Kommentar des init-Skriptes)

Es ging darum, dass die logs in /var/cache und nicht in /var/log (default) landen. In den Initscripten und Aufrufparametern, sehe ich nichts, was dieses Verhalten ändern würde.

Das mit uuid hatte ich in meinem Wahn wohl "vertippt". In der manpage gibt es user und uuid. Wo ist der Unterschied?
Das mit den Usern werde ich versuchen. Aber ich verstehe nicht, wieso das von Relevanz ist. Ein User kann doch soviele Instanzen laufen lassen, wie er will. Kennt UPnP überhaupt User-Namen?

[smutbert]

Keine Ahnung, so viel habe ich mit minidlna noch nie gemacht. Es könnte ja auch eine Schwäche von minidlna sein, dass es verschiedene Benutzer braucht?

Das Verzeichnis für die Logdateien wird im initskript festgelegt mit der defaulteinstellung /var/log, wenn in /etc/default/minidlna nichts anderes festgelegt ist - genau dort kann man auch den Benutzer festlegen - bei zwei Instanzen und unterschiedlichen Benutzern ist also auch eine Änderung am initskript notwendig.
Warum die Log bei dir nicht in /var/log landen, weiß ich nicht. bei mir sind sie wie in den /etc/default/minidlna angegeben in /var/log

[MoonKid]

wenn in /etc/default/minidlna nichts anderes festgelegt ist - genau dort kann man auch den Benutzer festlegen - bei zwei Instanzen und unterschiedlichen Benutzern ist also auch eine Änderung am initskript notwendig.

Das ist nicht ganz richtig. USER wird dort zwar zuerst gesetzt, dann aber wieder in /etc/init.d/minidlna gelöscht (mit unset), um dann den dortigen festkodierten default-User minidlna zu nutzen.

Wie bereits erwähnt, hatte ich unter Jessie wegen einem Bug nicht die Möglichkeit minidlna manuell zu starten. Hab jetzt daher auf mein unstable gewechselt.
Dort habe ich (unabhängig von SystemD) zwei Instanzen manuell gestartet. Dort habe ich explizit die Aufrufoption -u genutzt, um den zweiten User (den ich vorher angelegt habe) zu bestimmen. Auch in diesem Fall ändert sich nix am Verhalten.

Nebenbei gibt aber (wenn ich das überblicke) minidlna auch im Debug-Mode keine Ausgabe darüber, welche Konfigparameter (z.B. User) es jetzt tatsächlich verwendet.

[smutbert]

wenn in /etc/default/minidlna nichts anderes festgelegt ist - genau dort kann man auch den Benutzer festlegen - bei zwei Instanzen und unterschiedlichen Benutzern ist also auch eine Änderung am initskript notwendig.

Das ist nicht ganz richtig. USER wird dort zwar zuerst gesetzt, dann aber wieder in /etc/init.d/minidlna gelöscht (mit unset), um dann den dortigen festkodierten default-User minidlna zu nutzen.
[…]

Doch das ist richtig, zumindest in jessie. Ich poste hier einmal nur die relevanten Zeilen, in der Reihenfolge, in der sie im Startskript stehen

Code: Alles auswählen

…
unset USER

…
DEFAULT=/etc/default/$NAME

…

# Read configuration variable file if it is present
[ -r $DEFAULT ] && . $DEFAULT

…

# Set the default configuration file
if [ -z $CONFIGFILE ]; then
	CONFIGFILE=/etc/minidlna.conf
fi

…

# Run as `minidlna' if USER is not specified or is `root'
if [ -z $USER ]; then
	USER=minidlna
fi

# If no group is specified, use USER
if [ -z $GROUP ]; then
	GROUP=$USER
fi

do_start()
{
	…
	start-stop-daemon --start --quiet --pidfile $PIDFILE \
		--chuid $USER:$GROUP --exec $DAEMON --test > /dev/null \
		|| return 1
	start-stop-daemon --start --quiet --pidfile $PIDFILE \
		--chuid $USER:$GROUP --exec $DAEMON -- \
		$DAEMON_ARGS \
		|| return 2
}

…

Zuerst wird also zwar die Umgebungsvariable USER gelöscht, aber erst danach wird /etc/default/minidlna eingelesen und dort falls vorhanden USER gesetzt. Erst dann werden USER und GROUP auf den default (minidlane für USER und $USER für GROUP) gesetzt, aber nur wenn sie davor noch nicht gesetzt wurden.
Dass zwischen den beiden /etc/minidlna.conf eingelesen wird ist ohne Belang, weil darin nicht USER sondern user gesetzt wird (das passt mit dem Hinweis in der manpage zusammen, dass sich die minidlna.conf hier nicht auswirkt). Schließlich wird minidlan als $USER:$GROUP gestartet.

Als welcher user minidlna läuft kannst du auch einfach mit

Code: Alles auswählen

$ ps aux | grep minidlna

prüfen.

[MoonKid]

Doch das ist richtig, zumindest in jessie. Ich poste hier einmal nur die relevanten Zeilen, in der Reihenfolge, in der sie im Startskript stehen

Ach und ich dachte, ich hätte mal was entdeckt und verstanden! Du hast natürlich recht. (bash-script-for-humans-bashing snipped)

Als welcher user minidlna läuft kannst du auch einfach mit

Code: Alles auswählen

$ ps aux | grep minidlna

prüfen.

Sehr nützlicher Tip. Kommt gleich in mein Werkzeugkästchen.

[smutbert]

so und ich schreibe jetzt auf einmal ständig minidlan statt minidlna - das erklärt auch wieso meine systemd-units beim Testen ständig scheitern

[MoonKid]

Bähm!

Bin ich der Einzige der das noch nicht vertanden hatte? Die UID ist nicht die UUID. Das was minidlna UUID nennt, ist die "UPnP UUID". Mir war nicht bewusst, dass im UPnP Protokoll jede Instanz noch eine Identifikation benötigt - is ja logisch, wenn man drüber nachdenkt. minidlna setzt per default die MAC-Adresse als UUID. Setzt man den Parameter explizit funktioniert es sofort.

Diesbezüglich wurde die manpage jetzt auch angepasst.

Wie setzt man den Thread jetzt auf "[gelöst]"?

[smutbert]

dass die uuid aus der MAC erzeugt wird war das erste was ich gelesen habe, aber das nächste war dann die Behauptung in der Manpage, dass es die User ID ist... für mich war das zu viel der Verwirrung - danke für die Klärung.

Du kannst einfach den Eröffnungspost bearbeiten und dem Titel ein [gelöst] voranstellen.