( gelöst) Startreihenfolge von Systemdiensten ändern
( gelöst) Startreihenfolge von Systemdiensten ändern
Hi Leute,
ich habe ein kleines Problem mit "miniDLNA" auf meinem OpenMediaVault 6 NAS, Debian 11.
Der miniDLNA-Server zeigt mir keine Ordnerstruktur an, weil er vor dem mount des Dateisystems der Daten-SSD gestartet wird.
Der Fehler wird bei Eingabe von "service minidlna status" auch angezeigt.
Starte ich Ihn dann händisch aus der Konsole mit "service minidlna restart" ist alles Ok.
Wie kann man die Startreihenfolge der Dienste ändern oder zumindest den Dienst miniDLNA zeitlich verzögern, bis das Dateisystem hochgefahren ist.
Gruß orcape
ich habe ein kleines Problem mit "miniDLNA" auf meinem OpenMediaVault 6 NAS, Debian 11.
Der miniDLNA-Server zeigt mir keine Ordnerstruktur an, weil er vor dem mount des Dateisystems der Daten-SSD gestartet wird.
Der Fehler wird bei Eingabe von "service minidlna status" auch angezeigt.
Starte ich Ihn dann händisch aus der Konsole mit "service minidlna restart" ist alles Ok.
Wie kann man die Startreihenfolge der Dienste ändern oder zumindest den Dienst miniDLNA zeitlich verzögern, bis das Dateisystem hochgefahren ist.
Gruß orcape
Zuletzt geändert von orcape am 13.01.2022 15:55:38, insgesamt 1-mal geändert.
Re: Startreihenfolge von Systemdiensten ändern
Mountest du die SSD manuell bzw. durch ein eigenes Skript? Laut Service-Unit sollte der Dienst starten, nachdem alle lokalen bzw. entfernten Dateisysteme eingehängt sind.
Re: Startreihenfolge von Systemdiensten ändern
Hi,
und Danke erst mal für Dein Feedback.
Die Datenplatten werden über die "/etc/fstab" automatisch gemountet.
Wenn das NAS hochgefahren ist und ich mit "service minidlna status" den Dienst abfrage, ist der Dienst zwar gestartet, es erscheint aber eine Fehlermeldung zur freigegebenen SSD und deren Ordnerstrukturen.
Der miniDLNA-Server wird auf dem TV zwar angezeigt, aber es fehlt die Ordnerstruktur.
Fahre ich den Dienst mit "service minidlna restart" anschließend noch einmal hoch, ist "die Welt in Ordnung", zumindest was miniDLNA betrifft.
Darum meine Vermutung, das der Dienst vor den Datenplatten gestartet wird.
Gruß orcape
und Danke erst mal für Dein Feedback.
Die Datenplatten werden über die "/etc/fstab" automatisch gemountet.
Code: Alles auswählen
UUID=c1947eea-d064-4f81-a48a-1306e905cfc7 / ext4 noatime,nodiratime,errors=remount-ro 0 1
# /home was on /dev/sda6 during installation
# UUID=ed43684b-54e7-4da6-a147-1f5d060e788e /home ext4 defaults 0 2
# swap was on /dev/sda5 during installation
UUID=f4cbeda6-dc79-4d41-92e1-331c5a5e9f80 none swap sw 0 0
# >>> [openmediavault]
/dev/disk/by-uuid/9f5ec7e4-d9a4-4e09-bc09-435409a4d994 /srv/dev-disk-by-uuid-9f5ec7e4-d9a4-4e09-bc09-435409a4d994 ext4 defaults,nofail,user_xattr,usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0,acl 0 2
/dev/disk/by-uuid/ed43684b-54e7-4da6-a147-1f5d060e788e /srv/dev-disk-by-uuid-ed43684b-54e7-4da6-a147-1f5d060e788e ext4 defaults,nofail,user_xattr,usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0,acl 0 2
# <<< [openmediavault]
Code: Alles auswählen
root@bluesky:~#service minidlna status
● minidlna.service - MiniDLNA lightweight DLNA/UPnP-AV server
Loaded: loaded (/lib/systemd/system/minidlna.service; enabled; vendor preset: enabled)
Active: active (running) since Wed 2022-01-05 08:28:02 CET; 12min ago
Docs: man:minidlnad(1)
man:minidlna.conf(5)
Main PID: 568 (minidlnad)
Tasks: 2 (limit: 2309)
Memory: 13.5M
CPU: 853ms
CGroup: /system.slice/minidlna.service
└─568 /usr/sbin/minidlnad -f /etc/minidlna.conf -P /run/minidlna/minidlna.pid -S -r
Jan 05 08:28:02 bluesky systemd[1]: Started MiniDLNA lightweight DLNA/UPnP-AV server.
Jan 05 08:28:05 bluesky minidlnad[568]: [2022/01/05 08:28:05] minidlna.c:670: error: Media directory "/srv/dev-disk-by-uuid-9f5ec7e4-d9a4-4e09-bc09-435409a4d994/config/" not accessible [No such file or directory]
Jan 05 08:28:05 bluesky minidlnad[568]: [2022/01/05 08:28:05] minidlna.c:670: error: Media directory "A,/srv/dev-disk-by-uuid-9f5ec7e4-d9a4-4e09-bc09-435409a4d994/Musik/" not accessible [No such file or directory]
Jan 05 08:28:05 bluesky minidlnad[568]: [2022/01/05 08:28:05] minidlna.c:670: error: Media directory "P,/srv/dev-disk-by-uuid-9f5ec7e4-d9a4-4e09-bc09-435409a4d994/Pictures/" not accessible [No such file or directory]
Jan 05 08:28:05 bluesky minidlnad[568]: [2022/01/05 08:28:05] minidlna.c:670: error: Media directory "V,/srv/dev-disk-by-uuid-9f5ec7e4-d9a4-4e09-bc09-435409a4d994/Videos/" not accessible [No such file or directory]
Fahre ich den Dienst mit "service minidlna restart" anschließend noch einmal hoch, ist "die Welt in Ordnung", zumindest was miniDLNA betrifft.
Darum meine Vermutung, das der Dienst vor den Datenplatten gestartet wird.
Gruß orcape
Re: Startreihenfolge von Systemdiensten ändern
Wie sind die Ausgaben von:orcape hat geschrieben:05.01.2022 08:45:27Die Datenplatten werden über die "/etc/fstab" automatisch gemountet.
Code: Alles auswählen
systemctl cat minidlna
systemd-delta --type=extended
systemctl list-unit-files | grep -i fs.target
Re: Startreihenfolge von Systemdiensten ändern
Hi mat6937,
hier die Daten.....
Gruß orcape
hier die Daten.....
Code: Alles auswählen
root@bluesky:~#systemctl cat minidlna
# /lib/systemd/system/minidlna.service
[Unit]
Description=MiniDLNA lightweight DLNA/UPnP-AV server
Documentation=man:minidlnad(1) man:minidlna.conf(5)
After=local-fs.target remote-fs.target autofs
[Service]
User=minidlna
Group=minidlna
Environment=CONFIGFILE=/etc/minidlna.conf
Environment=DAEMON_OPTS=-r
EnvironmentFile=-/etc/default/minidlna
RuntimeDirectory=minidlna
LogsDirectory=minidlna
PIDFile=/run/minidlna/minidlna.pid
ExecStart=/usr/sbin/minidlnad -f $CONFIGFILE -P /run/minidlna/minidlna.pid -S $DAEMON_OPTS
[Install]
WantedBy=multi-user.target
Code: Alles auswählen
[EXTENDED] /usr/lib/systemd/system/clamav-daemon.service → /etc/systemd/system/clamav-daemon.service.d/extend.conf
[EXTENDED] /usr/lib/systemd/system/collectd.service → /etc/systemd/system/collectd.service.d/openmediavault.conf
[EXTENDED] /usr/lib/systemd/system/rc-local.service → /usr/lib/systemd/system/rc-local.service.d/debian.conf
[EXTENDED] /usr/lib/systemd/system/systemd-localed.service → /usr/lib/systemd/system/systemd-localed.service.d/locale-gen.conf
4 overridden configuration files found.
Code: Alles auswählen
root@bluesky:~#systemctl list-unit-files | grep -i fs.target
initrd-fs.target static -
initrd-root-fs.target static -
local-fs.target static -
remote-fs.target enabled enabled
Re: Startreihenfolge von Systemdiensten ändern
Eigentlich sollte die Zeile mit "After= ..." dafür sorgen, dass minidlna nach dem mount des Dateisystems der Daten-SSD, gestartet wird.orcape hat geschrieben:06.01.2022 09:02:27Code: Alles auswählen
root@bluesky:~#systemctl cat minidlna # /lib/systemd/system/minidlna.service [Unit] Description=MiniDLNA lightweight DLNA/UPnP-AV server Documentation=man:minidlnad(1) man:minidlna.conf(5) After=local-fs.target remote-fs.target autofs
Schau mal nach ob es die service-unit:
Code: Alles auswählen
systemctl status systemd-time-wait-sync.service
Code: Alles auswählen
After=systemd-time-wait-sync.service
Code: Alles auswählen
systemctl daemon-reload
systemctl restart minidlna
Code: Alles auswählen
systemctl status minidlna
systemctl cat minidlna
Code: Alles auswählen
systemd-analyze blame
systemctl status minidlna
Code: Alles auswählen
systemctl restart minidlna
Re: Startreihenfolge von Systemdiensten ändern
Hi,
"systemctl status systemd-time-wait-sync.service" ist geladen, aber inaktiv.
Ich habe in die Datei "/lib/systemd/system/minidlna.service", die Zeile "After=systemd-time-wait-sync.service" eingefügt, aber da der Service "time-wait" nicht läuft, ist dieses wohl sowieso obsolet.
Hier die Ausgabe von "systemd-analyze blame".....
...wo der Service dann natürlich nicht erscheint.
Mit "systemctl restart minidlna" und "systemctl status minidlna" ist natürlich wieder alles Tacco, was mir aber nicht wirklich weiterhilft.
Gruß orcape
"systemctl status systemd-time-wait-sync.service" ist geladen, aber inaktiv.
Code: Alles auswählen
root@bluesky:~#systemctl status systemd-time-wait-sync.service
● systemd-time-wait-sync.service - Wait Until Kernel Time Synchronized
Loaded: loaded (/lib/systemd/system/systemd-time-wait-sync.service; disabled; vendor preset: d>
Active: inactive (dead)
Docs: man:systemd-time-wait-sync.service(
Hier die Ausgabe von "systemd-analyze blame".....
Code: Alles auswählen
root@bluesky:~#systemd-analyze blame
34.056s openmediavault-issue.service
10.900s docker.service
7.102s postfix@-.service
3.105s containerd.service
2.231s systemd-networkd-wait-online.service
2.123s php7.4-fpm.service
2.119s dev-sda1.device
1.910s systemd-random-seed.service
1.747s systemd-fsck@dev-disk-by\x2duuid-9f5ec7e4\x2dd9a4\x2d4e09\x2dbc09\x2d435409a4d994.service
1.734s proftpd.service
1.732s loadcpufreq.service
1.698s nginx.service
1.559s openmediavault-engined.service
931ms ssh.service
929ms rrdcached.service
787ms keyboard-setup.service
774ms systemd-journald.service
652ms monit.service
650ms chrony.service
639ms systemd-udev-trigger.service
636ms user@1000.service
632ms systemd-resolved.service
617ms apparmor.service
603ms collectd.service
581ms systemd-journal-flush.service
545ms systemd-logind.service
501ms phpsessionclean.service
497ms networking.service
470ms systemd-networkd.service
449ms openmediavault-beep-up.service
416ms modprobe@drm.service
387ms lvm2-monitor.service
362ms srv-dev\x2ddisk\x2dby\x2duuid\x2ded43684b\x2d54e7\x2d4da6\x2da147\x2d1f5d060e788e.mount
335ms e2scrub_reap.service
315ms modprobe@fuse.service
274ms avahi-daemon.service
251ms run-rpc_pipefs.mount
240ms rpcbind.service
229ms systemd-fsck@dev-disk-by\x2duuid-ed43684b\x2d54e7\x2d4da6\x2da147\x2d1f5d060e788e.service
222ms systemd-modules-load.service
221ms quotaon.service
210ms systemd-update-utmp.service
204ms wpa_supplicant.service
201ms systemd-user-sessions.service
178ms cpufrequtils.service
170ms systemd-remount-fs.service
168ms modprobe@configfs.service
161ms systemd-sysusers.service
141ms dev-mqueue.mount
132ms systemd-tmpfiles-setup.service
130ms sys-kernel-debug.mount
129ms systemd-quotacheck.service
128ms systemd-udevd.service
124ms rsyslog.service
122ms sys-kernel-tracing.mount
104ms kmod-static-nodes.service
98ms clamav-daemon.service
86ms watchdog.service
86ms systemd-tmpfiles-clean.service
79ms systemd-sysctl.service
67ms systemd-tmpfiles-setup-dev.service
65ms dev-disk-by\x2duuid-f4cbeda6\x2ddc79\x2d4d41\x2d92e1\x2d331c5a5e9f80.swap
59ms nfs-blkmap.service
56ms console-setup.service
55ms systemd-update-utmp-runlevel.service
51ms nfs-config.service
46ms openmediavault-cleanup-monit.service
44ms user-runtime-dir@1000.service
32ms ifupdown-pre.service
31ms tmp.mount
23ms openmediavault-cleanup-php.service
19ms sys-fs-fuse-connections.mount
16ms sys-kernel-config.mount
12ms postfix.service
11ms docker.socket
281us blk-availability.service
Mit "systemctl restart minidlna" und "systemctl status minidlna" ist natürlich wieder alles Tacco, was mir aber nicht wirklich weiterhilft.
Gruß orcape
Re: Startreihenfolge von Systemdiensten ändern
OK, dann ersetze die Zeile:orcape hat geschrieben:06.01.2022 12:24:01"systemctl status systemd-time-wait-sync.service" ist geladen, aber inaktiv.
Code: Alles auswählen
After=systemd-time-wait-sync.service
Code: Alles auswählen
After=systemd-networkd-wait-online.service openmediavault-issue.service docker.service containerd.service
EDIT:
Poste sofort nach dem booten, die Ausgabe von:
Code: Alles auswählen
systemd-analyze blame | grep -i minidlna
Re: Startreihenfolge von Systemdiensten ändern
Hi mat6937,
die Änderungen in der "/lib/systemd/system/minidlna.service" haben nichts gebracht.
Bei Eingabe "systemd-analyze blame | grep -i minidlna" keine Ausgabe.
Die Email-Meldungen des OMV-Systems geben "zeitverzögert", das mounten der Datenpartition an. Erst erscheint eine Meldung das die Partition keinen Mountpoint hat, einige Sekunden später ist Sie dann, lt. E-Mail gemountet und wenn in diesem Zeitraum der Boot des miniDLNA-Dienstes passiert, wird eben kein Dateisystem erkannt.
Die Datenplatten des OMV stehen zwar als Einträge in der fstab, aber mit dem Hinweis, das es wohl ein OMV-Eintrag ist.... # >>> [openmediavault] Daten-SSD # <<< [openmediavault]
Nun ist der Dienst "miniDLNA" als Plugin unter OpenMediaVault-Extras installiert und ob nun Systemdienste des Debian11, die wohl zwangsläufig auch vom OMV genutzt werden, überhaupt so problemlos geändert werden können, ohne Probleme im OMV zu verursachen, ist fraglich. Die Installation dieses "Plugins" erfordert neben dem Openmediavault-minidlna Paket aber letztlich auch die Installation des Debian eigenen minidlna-Pakets.
Mir fallen eigentlich nur noch 2 Möglichkeit ein,
- das miniDLNA-Plugin auf dem OMV zu entfernen und miniDLNA auf dem Debian11-System installieren, mit Verweis auf die Datenplatte des OMV. (fraglich ob es das Problem fixt)
- nach boot der OMV-Daten-SSD, einen automatischen Neustart des miniDLNA-Service mittels Script, zu veranlassen.
Letzteres sollte das Problem eigentlich fixen, da es bei händischem Neustart des Service, ja auch funktioniert.
Nur bin ich nicht so der Fachmann für "Scripte" und wenn mir da eine "Vorlage" fehlt, von der ich inspiriert werde, werde ich daran wohl scheitern.
Gruß orcape
die Änderungen in der "/lib/systemd/system/minidlna.service" haben nichts gebracht.
Bei Eingabe "systemd-analyze blame | grep -i minidlna" keine Ausgabe.
Die Email-Meldungen des OMV-Systems geben "zeitverzögert", das mounten der Datenpartition an. Erst erscheint eine Meldung das die Partition keinen Mountpoint hat, einige Sekunden später ist Sie dann, lt. E-Mail gemountet und wenn in diesem Zeitraum der Boot des miniDLNA-Dienstes passiert, wird eben kein Dateisystem erkannt.
Die Datenplatten des OMV stehen zwar als Einträge in der fstab, aber mit dem Hinweis, das es wohl ein OMV-Eintrag ist.... # >>> [openmediavault] Daten-SSD # <<< [openmediavault]
Nun ist der Dienst "miniDLNA" als Plugin unter OpenMediaVault-Extras installiert und ob nun Systemdienste des Debian11, die wohl zwangsläufig auch vom OMV genutzt werden, überhaupt so problemlos geändert werden können, ohne Probleme im OMV zu verursachen, ist fraglich. Die Installation dieses "Plugins" erfordert neben dem Openmediavault-minidlna Paket aber letztlich auch die Installation des Debian eigenen minidlna-Pakets.
Mir fallen eigentlich nur noch 2 Möglichkeit ein,
- das miniDLNA-Plugin auf dem OMV zu entfernen und miniDLNA auf dem Debian11-System installieren, mit Verweis auf die Datenplatte des OMV. (fraglich ob es das Problem fixt)
- nach boot der OMV-Daten-SSD, einen automatischen Neustart des miniDLNA-Service mittels Script, zu veranlassen.
Letzteres sollte das Problem eigentlich fixen, da es bei händischem Neustart des Service, ja auch funktioniert.
Nur bin ich nicht so der Fachmann für "Scripte" und wenn mir da eine "Vorlage" fehlt, von der ich inspiriert werde, werde ich daran wohl scheitern.
Gruß orcape
Re: Startreihenfolge von Systemdiensten ändern
Versuch mal mit einer timer-unit, die die minidlna.service.unit, 45 Sekunden nach dem booten startet.orcape hat geschrieben:06.01.2022 18:14:51Nur bin ich nicht so der Fachmann für "Scripte" und wenn mir da eine "Vorlage" fehlt, von der ich inspiriert werde, werde ich daran wohl scheitern.
Wie man eine timer-unit erstellt, findest Du im Internet. U. a. auch im https://wiki.ubuntuusers.de/systemd/Timer_Units/
Für den Start via timer-unit, muss die service-unit deaktiviert (disabled) sein. Poste mal die Ausgabe von:
Code: Alles auswählen
systemctl is-enabled minidlna.service
Re: Startreihenfolge von Systemdiensten ändern
Code: Alles auswählen
root@bluesky:~#systemctl is-enabled minidlna.service
enabled
Re: Startreihenfolge von Systemdiensten ändern
Hi,
ich habe das Problem mit "sleepd" gelöst, indem ich den Start von "minidlna" zeitlich verzögert habe.
Die SSD wird nun von dem verspätet startenden "minidlna-Dienst" erkannt.
Gruß orcape
ich habe das Problem mit "sleepd" gelöst, indem ich den Start von "minidlna" zeitlich verzögert habe.
Die SSD wird nun von dem verspätet startenden "minidlna-Dienst" erkannt.
Gruß orcape