[gelöst] zweite Instanz von MiniDLNA

Alle weiteren Dienste, die nicht in die drei oberen Foren gehören.
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: 8331
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