minidlna launches before the media directories are mounted
jpo234 opened this issue · 26 comments
Description of issue/question
After a reboot, minidlna doesn't serve any content.
Steps to reproduce issue
Reboot the OMV server and try to access content through UPnP:
pi@omv-nas:~ $ 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 Sun 2020-12-13 20:03:51 CET; 1h 56min ago
Docs: man:minidlnad(1)
man:minidlna.conf(5)
Process: 733 ExecStart=/usr/sbin/minidlnad -f $CONFIGFILE -P /run/minidlna/minidlna.pid $DAEMON_OPTS (code=exited, status=0/SUCCESS)
Main PID: 902 (minidlnad)
Tasks: 2 (limit: 1430)
CGroup: /system.slice/minidlna.service
└─902 /usr/sbin/minidlnad -f /etc/minidlna.conf -P /run/minidlna/minidlna.pid -r
Dec 13 20:03:47 omv-nas systemd[1]: Starting MiniDLNA lightweight DLNA/UPnP-AV server...
Dec 13 20:03:51 omv-nas minidlnad[733]: [2020/12/13 20:03:51] minidlna.c:631: error: Media directory "V,/srv/dev-disk-by-label-omvmaster/Video/" not accessible [No such file or directory]
Dec 13 20:03:51 omv-nas minidlnad[733]: [2020/12/13 20:03:51] minidlna.c:631: error: Media directory "A,/srv/dev-disk-by-label-omvmaster/Music/" not accessible [No such file or directory]
Dec 13 20:03:51 omv-nas minidlnad[733]: [2020/12/13 20:03:51] minidlna.c:631: error: Media directory "P,/srv/dev-disk-by-label-omvmaster/Photos/" not accessible [No such file or directory]
Dec 13 20:03:51 omv-nas systemd[1]: Started MiniDLNA lightweight DLNA/UPnP-AV server.
Obviously the minidlna service should depend on the media directories to be available. Mine are on two external USB drives.
Versions report
The plugin doesn't maintain the unit file for minidlna. I guess I could add an override file but if local-fs.target doesn't work, it would have to be this somewhat ugly hack - https://github.com/OpenMediaVault-Plugin-Developers/openmediavault-omvextrasorg/blob/master/usr/sbin/omv-installdocker#L310.
@ryecoaaron We are ninyaing each other. As I wrote in the OMV repo: please close one of the reports. I don't know where you want to continue the discussion.
@jpo234 I did delete my message from the openmediavault issue but I can't close that one. You can continue here.
IMO using a systemd override is the only solution to fix that downstream. But in the end this should be fixed finally upstream in the minidlna Debian package or the project itself.
Is there a systemd target that says "all file systems ready for use"? The hackish solution that @ryecoaaron pointed to seems unreliable. All unit files would have to be regenerated, if the user adds an additional external mount...
Is there a systemd target that says "all file systems ready for use"? The hackish solution that @ryecoaaron pointed to seems unreliable. All unit files would have to be regenerated, if the user adds an additional external mount...
I fear there is no final solution for that because file systems may be mounted on demand via systemd nowadays (that's not the case for OMV, but nevertheless it is somewhat async), thus they are not available at a specific time.
It is hackish but not unreliable. It has been working for people for docker. The worst thing that can happen is you add a new filesystem that it isn't waiting for. That could be added to a listener to keep it up to date. Only the minidlna unit override file would have to be regenerated. Not a big deal.
That could be added to a listener to keep it up to date.
I'm unfamiliar with the systemd vocabulary, bur listener sounds intriguing. IMHO the right solution would be to tell minidlna that a new data filesystem just became available (as opposed to plethora of non-data filesystems). Right now this would have to restart minidlna. Can this be done purely from the unit files? Does systemd already call listeners when a mount completed? That would fix the async issue that @votdev mentioned.
Listeners are an OMV function. When a filesystem is added (has to be done via OMV web interface), it would update the override file and do a systemctl daemon-reload. If you are adding filesystems outside of OMV, then you are out of luck. The only way to do that would be to script it and run via cron. Either way, minidlna would not have to be restarted unless you are changing the minidlna config file.
New to the project.
I face this problem as well. On every reboot, I lose all access to minidlna shares.
I was able to manually add an edit to the minidlna.service as an override.
systemctl edit minidlna.service
Added
[Unit]
RequiresMountsFor=/srv/{UUID name of the media drive}
See https://www.freedesktop.org/software/systemd/man/systemd.unit.html Systemd.Unit man page
RequiresMountsFor=¶
Takes a space-separated list of absolute paths. Automatically adds dependencies of type Requires= and After= for all mount units required to access the specified path.Mount points marked with noauto are not mounted automatically through local-fs.target, but are still honored for the purposes of this option, i.e. they will be pulled in by this unit.
Not sure if this helps.
That is the fix I was suggesting. Already doing that for docker.
I wonder if there is a way to define a target that waits for the shared folders to be mounted so that the other omv targets could wait on one central dependency. Basically a separate unit that does nothing but the
RequiresMountsFor=/srv/whatever
@votdev What do you think about creating a target that is updated any time the fstab module is run that would contain an After and/or Requires listing all filesystems? Then plugins such as this one could add overrides to run After this new target. I am doing something similar for docker in omvextras (it is waiting for mount unit files) https://github.com/OpenMediaVault-Plugin-Developers/openmediavault-omvextrasorg/blob/master/usr/sbin/omv-installdocker#L310
@votdev What do you think about creating a target that is updated any time the fstab module is run that would contain an After and/or Requires listing all filesystems? Then plugins such as this one could add overrides to run After this new target. I am doing something similar for docker in omvextras (it is waiting for mount unit files) https://github.com/OpenMediaVault-Plugin-Developers/openmediavault-omvextrasorg/blob/master/usr/sbin/omv-installdocker#L310
Target for what? OMV does not have a systemd unit file for fstab. Could you please describe your idea more detailed?
Right now local-fs.target doesn't seem to work for waiting for all mount points to be mounted. So, services like minidlna or docker or nfs will start before the filesystem with its database is mounted. If we created a target (/lib/systemd/system/omv-fs.target for example) that looked something like:
[Unit]
Description=Wait for OMV filesystems target
Requires=multi-user.target
Wants=local-fs.target
After=local-fs.target $(systemctl list-units --type=mount | grep /srv | awk '{ print $1 }' | tr '\n' ' ')
Then other services could have overrides added to wait/require this target to make sure they didn't start before the filesystems were mounted.
Right now local-fs.target doesn't seem to work for waiting for all mount points to be mounted. So, services like minidlna or docker or nfs will start before the filesystem with its database is mounted. If we created a target (/lib/systemd/system/omv-fs.target for example) that looked something like:
[Unit]
Description=Wait for OMV filesystems target
Requires=multi-user.target
Wants=local-fs.target
After=local-fs.target $(systemctl list-units --type=mount | grep /srv | awk '{ print $1 }' | tr '\n' ' ')Then other services could have overrides added to wait/require this target to make sure they didn't start before the filesystems were mounted.
Could you please open an issue to discuss that there? If there is no other solution to fix that, i'm fine to give it a try after various tests. I don't want to run into the same fiasco like we had with the shared folders unit file.
What is the output of systemctl list-units --type=mount in your example?
I will open an issue.
Any news? There were a number of minidlna updates lately and fixing my config after every update gets old really fast...
The problem is still there. In the forum I was given the tip to add a waiting time to minidlna.service
[Service]
StartLimitInterval=300s
ExecStartPre=/bin/sleep 30
@ryecoaaron @synaomen I think I posted this before: I'm launching minidlna After the quota check:
After=network.target systemd-quotacheck.service
Checking the disk quotas obviously requires the disks to be accessible.
@jpo234 If you use systemctl edit to create the override, you shouldn't have to fix that every time there is an update.
@ryecoaaron Thanks for the tip. Minidlna now works even after
sudo apt install --reinstall minidlna
sudo shutdown -r now
BTW, doing systemctl list-dependencies systemd-quotacheck.service --all --reverse shows that this does indeed do the right thing and wait until the external disks are mounted. Maybe it's the best we can do right now.
Description of issue/question
After a reboot, minidlna doesn't serve any content.
Steps to reproduce issue
Reboot the OMV server and try to access content through UPnP:
pi@omv-nas:~ $ 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 Sun 2020-12-13 20:03:51 CET; 1h 56min ago Docs: man:minidlnad(1) man:minidlna.conf(5) Process: 733 ExecStart=/usr/sbin/minidlnad -f $CONFIGFILE -P /run/minidlna/minidlna.pid $DAEMON_OPTS (code=exited, status=0/SUCCESS) Main PID: 902 (minidlnad) Tasks: 2 (limit: 1430) CGroup: /system.slice/minidlna.service └─902 /usr/sbin/minidlnad -f /etc/minidlna.conf -P /run/minidlna/minidlna.pid -r Dec 13 20:03:47 omv-nas systemd[1]: Starting MiniDLNA lightweight DLNA/UPnP-AV server... Dec 13 20:03:51 omv-nas minidlnad[733]: [2020/12/13 20:03:51] minidlna.c:631: error: Media directory "V,/srv/dev-disk-by-label-omvmaster/Video/" not accessible [No such file or directory] Dec 13 20:03:51 omv-nas minidlnad[733]: [2020/12/13 20:03:51] minidlna.c:631: error: Media directory "A,/srv/dev-disk-by-label-omvmaster/Music/" not accessible [No such file or directory] Dec 13 20:03:51 omv-nas minidlnad[733]: [2020/12/13 20:03:51] minidlna.c:631: error: Media directory "P,/srv/dev-disk-by-label-omvmaster/Photos/" not accessible [No such file or directory] Dec 13 20:03:51 omv-nas systemd[1]: Started MiniDLNA lightweight DLNA/UPnP-AV server.Obviously the minidlna service should depend on the media directories to be available. Mine are on two external USB drives.
Versions report
Si el usuario minidlna no puede acceder a las carpetas donde se encuentra nuestro contenido multimedia, definido en la directriz media_dir, habrá que añadirlo a los grupos pertinentes. En nuestro ejemplo, todas las carpetas pertenecen al grupo llamado jose que tiene permisos de lectura y ejecución.
ls -la
jose@jose-pc:~/PELICULAS$ ls -la
drwxrwxr-x 2 jose jose 4096 mar 16 15:29 .
drwxr-x--- 35 jose jose 4096 mar 16 17:16 ..
-rw-rw-r-- 1 jose jose 576804311 mar 16 10:40 '65 millones atras al borde extincion.mp4'
-rw------- 1 jose jose 878084096 mar 16 14:35 jj.mp4
-rw-rw-r-- 1 jose jose 1698000847 mar 16 12:56 'Pantera Negra Wakanda por siempre.mp4'
$ sudo gpasswd -a minidlna jose
Esto soluciono el problema