[gelöst] zweite Instanz von MiniDLNA

Alle weiteren Dienste, die nicht in die drei oberen Foren gehören.
MoonKid
Beiträge: 513
Registriert: 12.03.2012 22:36:43

Re: zweite Instanz von MiniDLNA

Beitrag von MoonKid » 10.02.2017 14:52:09

smutbert hat geschrieben: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".
smutbert hat geschrieben:Wenn wir aber endlich zwei Instanzen hinbekommen, würde ich vorschlagen, dass wir (du :mrgreen: ) 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.

Benutzeravatar
smutbert
Moderator
Beiträge: 8313
Registriert: 24.07.2011 13:27:39
Wohnort: Graz

Re: zweite Instanz von MiniDLNA

Beitrag von smutbert » 10.02.2017 15:19:36

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
man minidlna.conf hat geschrieben:[…]
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
Beiträge: 513
Registriert: 12.03.2012 22:36:43

Re: zweite Instanz von MiniDLNA

Beitrag von MoonKid » 10.02.2017 15:35:23

smutbert hat geschrieben: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?

Benutzeravatar
smutbert
Moderator
Beiträge: 8313
Registriert: 24.07.2011 13:27:39
Wohnort: Graz

Re: zweite Instanz von MiniDLNA

Beitrag von smutbert » 10.02.2017 15:46:57

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
Beiträge: 513
Registriert: 12.03.2012 22:36:43

Re: zweite Instanz von MiniDLNA

Beitrag von MoonKid » 10.02.2017 15:57:14

smutbert hat geschrieben: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.

Benutzeravatar
smutbert
Moderator
Beiträge: 8313
Registriert: 24.07.2011 13:27:39
Wohnort: Graz

Re: zweite Instanz von MiniDLNA

Beitrag von smutbert » 10.02.2017 19:19:48

MoonKid hat geschrieben:
smutbert hat geschrieben: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
Beiträge: 513
Registriert: 12.03.2012 22:36:43

Re: zweite Instanz von MiniDLNA

Beitrag von MoonKid » 11.02.2017 06:37:10

smutbert hat geschrieben: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! :mrgreen: :hail: Du hast natürlich recht. (bash-script-for-humans-bashing snipped)
smutbert hat geschrieben: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.

Benutzeravatar
smutbert
Moderator
Beiträge: 8313
Registriert: 24.07.2011 13:27:39
Wohnort: Graz

Re: zweite Instanz von MiniDLNA

Beitrag von smutbert » 11.02.2017 11:21:21

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 :facepalm:

MoonKid
Beiträge: 513
Registriert: 12.03.2012 22:36:43

Re: zweite Instanz von MiniDLNA

Beitrag von MoonKid » 11.02.2017 15:10:57

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]"?

Benutzeravatar
smutbert
Moderator
Beiträge: 8313
Registriert: 24.07.2011 13:27:39
Wohnort: Graz

Re: zweite Instanz von MiniDLNA

Beitrag von smutbert » 11.02.2017 17:31:36

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.

MoonKid
Beiträge: 513
Registriert: 12.03.2012 22:36:43

Re: zweite Instanz von MiniDLNA

Beitrag von MoonKid » 11.02.2017 20:12:14

Dem Debian Maintainer ist hierfür zu danken. Er hat mir das erklärt mit der UUID und sofort die manpager geändert.
Im übrigen finde ich bei Upstream überhaupt keine Dokumentation, Manpage, etc

scientific
Beiträge: 3020
Registriert: 03.11.2009 13:45:23
Lizenz eigener Beiträge: Artistic Lizenz
Kontaktdaten:

Re: [gelöst] zweite Instanz von MiniDLNA

Beitrag von scientific » 12.02.2017 10:30:15

Ohne alles detailliert mitgelesen zu haben...
Für systemd ist es gut, Dienste im Vordergrund zu starten. Meist haben Dienste eine Option --no-daemon oder so ähnlich. Das hat auch den Vorteil, dass die Meldungen direkt im Journal landen.

Ansonsten kann systemd einen sich forkenden Dienst auch überwachen wenn Type=forked gesetzt wird.

Die dbus-Geschichte hab ich noch nicht kapiert :-)

systemd kann ich sowohl User als auch Group mitgeben... Das ersetzt die Auswahl des Users aus dem Initskript ganz einfach.

systemctl cat minidlna.service sollte auch Auskunft über den Ort der Unit aber auch allfälliger Dropins geben.
Lg scientific
dann putze ich hier mal nur...

Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie

auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main

scientific
Beiträge: 3020
Registriert: 03.11.2009 13:45:23
Lizenz eigener Beiträge: Artistic Lizenz
Kontaktdaten:

Re: [gelöst] zweite Instanz von MiniDLNA

Beitrag von scientific » 12.02.2017 11:00:03

Ich habs soeben erfolgreich so getestet:

Code: Alles auswählen

# cat minidlna@.service 
[Unit]
Description=Mediaserver minidlna: %i
After=network-online.target
ConditionPathExists=/etc/minidlna.conf
PartOf=minidlna.service
ReloadPropagatedFrom=minidlna.service

[Service]
User=minidlna
Group=minidlna
RuntimeDirectory=%i
#ExecStart=/usr/sbin/minidlnad -S -f /etc/minidlna.conf -P /run/minidlna/minidlna.pid
ExecStart=/usr/sbin/minidlnad -S -f /etc/%i.conf -P /run/minidlna/%i.pid
#PIDFile=/run/minidlna/minidlna.pid

[Install]
WantedBy=network-online.target

Dann habe ich eine Konfigurationsdatei /etc/minidlna.service und /etc/minidlna2.service, die sich im media_dir= , port= und serial= unterscheiden.

Code: Alles auswählen

# systemctl daemon-reload
# systemctl start minidlna@minidlna.service minidlna@minidlna2.service
# systemctl status minidlna@minidlna.service minidlna@minidlna2.service
● minidlna@minidlna.service - Mediaserver minidlna: minidlna
   Loaded: loaded (/etc/systemd/system/minidlna@.service; disabled; vendor preset: enabled)
   Active: active (running) since Sun 2017-02-12 10:55:58 CET; 4s ago
 Main PID: 6726 (minidlnad)
    Tasks: 3 (limit: 4915)
   CGroup: /system.slice/system-minidlna.slice/minidlna@minidlna.service
           ├─6726 /usr/sbin/minidlnad -S -f /etc/minidlna.conf -P /run/minidlna/minidlna.pid
           └─6732 /usr/sbin/minidlnad -S -f /etc/minidlna.conf -P /run/minidlna/minidlna.pid

Feb 12 10:55:58 aldebaran systemd[1]: Started Mediaserver minidlna: minidlna.
Feb 12 10:55:58 aldebaran minidlnad[6726]: minidlna.c:1034: warn: Starting MiniDLNA version 1.1.6.
Feb 12 10:55:58 aldebaran minidlnad[6726]: minidlna.c:342: warn: New media_dir detected; rescanning...
Feb 12 10:55:58 aldebaran minidlnad[6726]: minidlna.c:1074: warn: HTTP listening on port 8200
Feb 12 10:55:58 aldebaran minidlnad[6726]: scanner.c:726: warn: /home/jakob/Musik wird gescannt ...
Feb 12 10:56:00 aldebaran minidlnad[6726]: tagutils/tagutils-ogg.c:186: warn: Malformed vorbis strem.
Feb 12 10:56:01 aldebaran minidlnad[6726]: tagutils/tagutils-ogg.c:186: warn: Malformed vorbis strem.
Feb 12 10:56:01 aldebaran minidlnad[6726]: tagutils/tagutils-ogg.c:186: warn: Malformed vorbis strem.
Feb 12 10:56:01 aldebaran minidlnad[6726]: tagutils/tagutils-ogg.c:186: warn: Malformed vorbis strem.

● minidlna@minidlna2.service - Mediaserver minidlna: minidlna2
   Loaded: loaded (/etc/systemd/system/minidlna@.service; disabled; vendor preset: enabled)
   Active: active (running) since Sun 2017-02-12 10:55:58 CET; 5s ago
 Main PID: 6727 (minidlnad)
    Tasks: 2 (limit: 4915)
   CGroup: /system.slice/system-minidlna.slice/minidlna@minidlna2.service
           └─6727 /usr/sbin/minidlnad -S -f /etc/minidlna2.conf -P /run/minidlna/minidlna2.pid

Feb 12 10:55:58 aldebaran systemd[1]: Started Mediaserver minidlna: minidlna2.
Feb 12 10:55:58 aldebaran minidlnad[6727]: minidlna.c:1034: warn: Starting MiniDLNA version 1.1.6.
Feb 12 10:55:58 aldebaran minidlnad[6727]: minidlna.c:1074: warn: HTTP listening on port 8201

Läuft also mit zwei unterschiedlichen Instanzen und ohne init-Skript.

lg scientific
dann putze ich hier mal nur...

Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie

auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main

Benutzeravatar
smutbert
Moderator
Beiträge: 8313
Registriert: 24.07.2011 13:27:39
Wohnort: Graz

Re: [gelöst] zweite Instanz von MiniDLNA

Beitrag von smutbert » 12.02.2017 11:30:12

Das beantwortet gleich ein paar Fragen, die ich zu einer unit für mehrere Instanzen gestellt hätte., aber…

Was sind Dropins?
Wieso hast du "ConditionPathExists=/etc/minidlna.conf" in die unit geschrieben?
Und warum "WantedBy=network-online.target" und nicht einfach multi-user.target?

scientific
Beiträge: 3020
Registriert: 03.11.2009 13:45:23
Lizenz eigener Beiträge: Artistic Lizenz
Kontaktdaten:

Re: [gelöst] zweite Instanz von MiniDLNA

Beitrag von scientific » 12.02.2017 12:31:15

Eine genaue Erklärung folgt noch.
Das war nur ein Schnellschuß zwischen Tür und Angel am Sonntagmorgen...
dann putze ich hier mal nur...

Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie

auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main

scientific
Beiträge: 3020
Registriert: 03.11.2009 13:45:23
Lizenz eigener Beiträge: Artistic Lizenz
Kontaktdaten:

Re: [gelöst] zweite Instanz von MiniDLNA

Beitrag von scientific » 12.02.2017 13:16:34

Drop-In sind Config-Schnitzel in /etc/systemd/system/dienst.service.d/dropin.conf.

Damit kann man einzelne Werte der Units des Pakets überschreiben und ergänzen, ohne gleich eine neue Unit selbst zu schreiben.

Die ConditionPathExists hab ich noch nicht angepasst - Schnellschuß eben. Da gehört /etc/%i.conf hin.

network-online.target hab ich bei mir so angepasst, dass Networkmanager-dispatcher es bei fehlender Netzwerkverbindung wieder stoppt.
Und ohne Netzwerk ist minidlna auch ziemlich nutzlos... Könnt aber auch multi-user.target sein...

Als Ergänzung... systemctl start kann mehrere Units gleichzeitig starten.
Die beiden Instanzen unterscheiden sich im Namen des Konfigurationsfiles - in dem Port, serial das Runtimedir unterschiedlich sein müssen.

Das geht natürlich noch besser, und ich werds noch nachreichen.
dann putze ich hier mal nur...

Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie

auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main

MoonKid
Beiträge: 513
Registriert: 12.03.2012 22:36:43

Re: [gelöst] zweite Instanz von MiniDLNA

Beitrag von MoonKid » 12.02.2017 15:06:39

Ich sehe in deinem Beispiel nicht mal wo der zweite Aufruf von minidlnad ist.

scientific
Beiträge: 3020
Registriert: 03.11.2009 13:45:23
Lizenz eigener Beiträge: Artistic Lizenz
Kontaktdaten:

Re: [gelöst] zweite Instanz von MiniDLNA

Beitrag von scientific » 12.02.2017 15:31:46

MoonKid hat geschrieben:Ich sehe in deinem Beispiel nicht mal wo der zweite Aufruf von minidlnad ist.
Hier wird eine instanz mit mindlna und eine zweite mit minidlna2 gestartet.

Der Unterschied ist wie schon beschrieben, dass sich die beiden Instanzen im Namen (und natürlich Inhalt) der Konfigurations-Dateien unterscheiden.
%i wird in der Unit zu dem Aufgelöst, was zwischen @ und ".service" steht.

Code: Alles auswählen

# systemctl start minidlna@minidlna.service minidlna@minidlna2.service
Die Instanz heißt z.B. minidlna@minidlna.service -> damit wird %i in der Unit zu "minidlna". Das ganze aufgelöst ergibt dann den Aufruf

Code: Alles auswählen

ExecStart=/usr/sbin/minidlnad -S -f /etc/%i.conf -P /run/minidlna/%i.pid
wird zu

Code: Alles auswählen

ExecStart=/usr/sbin/minidlnad -S -f /etc/minidlna.conf -P /run/minidlna/minidlna.pid
und systemctl start minidlna@minidlna2.service wird zu

Code: Alles auswählen

ExecStart=/usr/sbin/minidlnad -S -f /etc/minidlna2.conf -P /run/minidlna/minidlna2.pid
Ich kann am Browser dann
http://localhost:8200 bzw. http://localhost:8201
entsprechend den beiden Konfigurationsfiles /etc/minidlna.conf und /etc/minidlna2.conf aufrufen und sehe unterschiedliche Status-Meldungen.

systemctl status minidlna@minidlna.service minidlna@minidlna2.service zeigt auch die entsprechenden Zustände beider Services direkt untereinander an.

Da diese Variante aber unschön ist, da ein sich beendender Dienst das RuntiimeDirectory löscht, und beide Instanzen ins selbe Directory schreiben (/run/minidlna) würde der zweite Dienst seines verlieren...
Und für eine Erweiterung einer "DefaultInstance" in der Unit brauche ich für den Namen des Konfigurationsfiles kein "-" im Namen, deshalb in der folgenden Variante drei Konfigurationsfiles
/etc/minidlna.conf (das Default-File der Installation)
/etc/minidlnavideo.conf
/etc/minidlnaaudio.conf

In den letzten beiden sind jeweils nur der Pfad zu Video- bzw. Audio-Verzeichnis enthalten.

Die Unit /etc/systemd/system/minidlna@.service:

Code: Alles auswählen

[# cat minidlna@.service 
[Unit]
Description=Mediaserver minidlna: %i
After=network-online.target
ConditionPathExists=/etc/minidlna%i.conf
PartOf=minidlna.service

[Service]
User=minidlna
Group=minidlna
RuntimeDirectory=minidlna%i
ExecStart=/usr/sbin/minidlnad -S -f /etc/minidlna%i.conf -P /run/minidlna%i/minidlna.pid

[Install]
WantedBy=network-online.target
Das File speichern und anschließend:

Code: Alles auswählen

# systemctl daemon-reload
# systemctl start minidlna@minidlnavideo.service minidlna@minidlnaaudio.service
ausgeführt und man hat zwei minidlna-Service als User minidlna laufen.

Wichtig ist noch die Bezeichnung
friendly_name="hostname: VIDEO" bzw. AUDIO zu setzen, damit man die auch noch im Client unterscheiden kann.

[EDIT]
https://spremi.wordpress.com/2014/06/30 ... instances/
Das Problem, dass entweder einer oder der andere am SmartTV/Handy-Client erscheint hab ich durch obigen Link lösen können.
Bei den beiden Configs /etc/minidlnavideos.conf und /etc/minidlnaaudio.conf am Ende noch eine Zeile mit
uuid=
und UNTERSCHIEDLICHEN(!!!!!) UUIDS einfügen.
Eine uuid kann man sich auf der Commandline mit uuidgen aus Debianuuid-runtime erzeugen.

Hab das noch eingefügt, beide Services neu gestartet und schon tauchen beide Services mit "hostname: VIDEO" und "hostname: AUDIO" in BubbleUPNP am Android-Handy auf.

minidlna ist bei mir in folgender Version am Gerät:

Code: Alles auswählen

# dpkg -l|grep minidlna
ii  minidlna                                                    1.1.6+dfsg-1                         amd64        lightweight DLNA/UPnP-AV server targeted at embedded systems
lg scientific
dann putze ich hier mal nur...

Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie

auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main

MoonKid
Beiträge: 513
Registriert: 12.03.2012 22:36:43

Re: [gelöst] zweite Instanz von MiniDLNA

Beitrag von MoonKid » 12.02.2017 20:02:23

Danke für deine detailierten und nachvollziehbaren Erläuterungen.

Den Part mit der UUID (aka UPnP UUID) hatte ich vorher schon hier erwähnt und daher den Thread auf "gelöst" gesetzt. Weil, dass das eigentliche Problem war. Die UUID (bei minidlna per default die MAC-Adresse) und UID (der Linux-Benutzer; z.B. minidlna) sind hier deutlich zu unterscheiden.

An deiner Unit würde mich interessieren, wie man die zum automatischen Starten (beim Booten) bringt? update-rc.d (also den Umweg, über die alten Init-Scripte) nutzt man ja hier nicht, wenn ich dich richtig verstanden habe.

Das deine Unit im engeren Sinne eine einzige Unit ist, kann ich verstehen und nachvollziehen. Aus (meiner) User-Sicht ist es aber nicht einfacher. In deinem Aufruf von systemctl musst du trotzdem zwei (auch noch komplizierte) Namen angeben, damit beide Instanzen gestartet werden. Wie baut man das in den Bootprozess ein? Die Unit selbst, weiß nicht von alleine, dass da zwei Instanzen zu starten sind. Das war nicht meine Vorstellung. Dieses %i ist IMO auch eine schön maschienentaugliche und weit entfernt vom User gedachter Ansatz. Am Ende ist es natürlich Geschmackssache.
Deine Lösung finde ich weniger eingängig (menschenverständlich) als meine Lösung mit zwei Init-Scripten.

Benutzeravatar
smutbert
Moderator
Beiträge: 8313
Registriert: 24.07.2011 13:27:39
Wohnort: Graz

Re: [gelöst] zweite Instanz von MiniDLNA

Beitrag von smutbert » 12.02.2017 20:22:25

(Einmalig) startest du mit

Code: Alles auswählen

# systemctl start minidlna@minidlna.service
# systemctl start minidlna@minidlna2.service
aktivieren, also dafür sorgen, dass sie automatisch gestartet werden kannst du mit

Code: Alles auswählen

# systemctl enable minidlna@minidlna.service
# systemctl enable minidlna@minidlna2.service

scientific
Beiträge: 3020
Registriert: 03.11.2009 13:45:23
Lizenz eigener Beiträge: Artistic Lizenz
Kontaktdaten:

Re: [gelöst] zweite Instanz von MiniDLNA

Beitrag von scientific » 12.02.2017 21:15:59

In der Tat muss ich gestehen (Asche auf mein Haupt), ich hab nicht alles gelesen, und dass du auf die Geschichte mit der uuid (scheint undokumentiert zu sein!) auch schon gekommen bist, hab ich übersehen.

Was systemd-units und "menschenverständlichkeit" anbelangt... nun... es ist systemd, und man muss sich damit beschäftigen. Ohne Beschäftigung mit einem Thema, geht es nun einmal nicht. Die Zeit, als du dich mit Initskripten und der Bash auseinandergesetzt hast, sind wohl auch schon eine Zeit her, und das ging dir in Fleisch und Blut über... aber ob ein ewig langes Init-Skript verständlicher ist, als ein paar Zeilen systemd-Unit, wage ich zu bezweifeln. Noch dazu, wo die Initskripte ohnehin per Automatismus in systemd-Units übergeführt werden...

Das Stichwort "instanziierende Systemd-Units" ist ein spannendes Kapitel und die sind genau für solche Anwendungsfälle gemacht. man übergibt dem Dienst quasi einen Parameter (und nur einen) im Unit-Name selbst.
Das schöne daran ist, dass viele Services schon solche Units mitliefern, und man sich darum keine Gedanken mehr machen muss. Man ruft sie einfach nur mehr auf. Minidlna geht halt davon aus, dass nur ein Dienst läuft... der Paketbetreuer auch... also gibts keine solche instanziierende Unit... gab es keine. Denn jetzt gibts eine, die ich dir geliefert habe.
Mit diesem einen Aufruf (und der entsprechenden Konfigurationsdatei in /etc/*) kannst du ohne viel Aufhebens auch 20 verschiedene minidlna-Dienste auf deinem Rechner starten.

Und wie smutbert schon schrieb... ein automatisches Starten beim Boot-Vorgang erreicht man mit "systemctl enable ". Aber das ist in der Tat nicht unbedingt Gegenstand dieses Threads. Das ist Grundwissen für systemd... und damit sollte man sich als Sys- oder Hobby-Admin von Debian schön langsam auseinanderzusetzen beginnen... Sorry, wenn ich da so ungut rüberkomme... Früher schrieb man RTFM. Ich sags nett. systemd kann man lernen. So kompliziert ist das nicht. :)

lg scientific
dann putze ich hier mal nur...

Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie

auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main

Antworten