Prevent MPD to start when HDD not mounted

Help and Support
#1

Hello,

From time to time, I am facing this situation: for any reason, my HDD is not present/mounted/etc… and, when mpd starts at boot, it justs erases the tag_cache file (because no music library can be seen).
So, when this happens, I need to rebuild again the tag_cache file, which can take a while.

What would be an easy way to prevent this?

In SystemV, I would modify manually /etc/init.d/mpd to check that the HDD can be seen before scanning it. But, with systemd, this would not work, because this script is not run.

I think that the mpd process is launched in /etc/systemd/system/multi-user.target.wants/mpd.service with this line:

ExecStart=/usr/bin/mpd --no-daemon

I could replace this with a simple script that checks the presence of HDD before running mpd. This is not very nice (I agree it is just an ugly solution…), but I think this would work.

Any “systemd” specialist here for a better way to do this? More “systemd oriented”?

Thanks in advance.

Denis
#2

First tell us which platform you are referring to (RPi, x86, ??).
I believe it would be better to help find the reason for the HDD not being mounted instead of fighting a symptom. Your solution, if it works, would disable the update mechanism. You would have to flash each new Volumio version and then redo the changes.

#3

Thanks for your reply.

The platform is RPI4, and I had the same issue with RPI3, it is not platform dependant… The problem is that when mpd starts and sees no music files, it just erases its database in a couple of seconds (I mean, it builds a new database which is empty).

Another way to solve this is to make a copy of the tag_cache file.

The reason why the HDD does not appear can be multiple. The HDD is a USB 2,5" 4To, and it works fine, but as it is external:

  • not connected: I made something on the RPI, and started it without plugging it again (I actually forgot to plug it…) Too bad.
  • the disk did not start properly (because the power supply was not strong enough…)
  • and so on… There can be multiple causes, these are only the two last ones…

When the HDD is properly connected, and the power supply is here, it works, no problem.

So I just want to secure the mpd database…

I found 2 “easy” ways to do it:

  1. using a ExecStartPre condition, which woul allow to wiat for the HDD to be actually present

[Service]
ExecStartPre=bash -c “unless [ -f /path/to/file ]; do sleep 1; done”
ExecStart=your_command

  1. Using a ConditionPathExistsn, which is only “one shot” (i.e does not wait for the file to be present)

[Unit]
ConditionPathExists=

And yes, I know I will have to redo this after upgrade of Volumio version. It’s not a problem.

#4

Interesting, I wonder how widespread this potential problem might be. Systemd can cause problems over timings with different endpoints being reached before other things are ready.

Has anyone else experienced this kind of problem?

#5

To be precise, it is not a Volumio issue, but rather a mpd one. I’ve been using mpd for a (long) while before Volumio, on an old eeepc. I could simply solve the issue by hacking the /etc/init.d/mpd script, because it was in SystemV.

#6

Yeah you’re totally right … I jumped in enthusiastically because I’ve had systemd problems in the past with timings. :wink: Your ‘ExecStartPre’ seems a good basis to start. Now to the important part, does it work ok?

You could do something similar with something like ExecStartPre=/bin/sleep 1 ??

At the end of the day, they’re still cludges, and finding out the cause is better than treating the symptoms.

#7

I’m not sure it’s a timing issue (or systemd issue), not in the case I describe anyway.

The issue is not that the “mount” is not ready, but clearly because the “mount” operation was not performed, and won’t be performed (for exemple because the HDD is not correctly plugged) if nothing is done.

Normally, with systemd, mpd is started after everything was mounted. So waiting 1s or an infinite time will not change anything, in that case.

But pooling once per second and waiting for a given file or directory to be present could do the job, for example in the case the HDD was not connected. Just connect it, it it should be OK.

Of ourse, this solution is mainly for USB mounts, and depends on the file name to be tested. Not easy to apply this in a general case.

I will test this maybe tomorrow, I’ll report the result here.

Denis

#8

Is it reproducible? If so collect the system log, and hopefully we can see what is happening.

Recording system logs .

#9

Looks ok now.

I modified the file mpd.service, adding just a line (ExecStartPre…)

…
[Service]
Type=notify
ExecStartPre=/bin/bash -c “while [ ! -d /mnt/USB/flac ]; do sleep 1; done”
ExecStart=/usr/bin/mpd --no-daemon

…

Then reloaded and reinstalled the service.

Rebooted, without the HDD => mpd is not launched, so tag_cache file is not “emptied”. Of course, no music can be played in this state, anyway there is no HDD…

Reconnect the HDD (hot plug), this makes mpd run.

Thanks for the hints and the help.

Denis
#10

I have a similar problem on an Allo USBridge Sig, and I am not using Volumio. I have my music files on a USB disk. Some bug has caused the permissions to change spontaneously so that mpd has no rights. When I issue

mpc --wait update

the database empties immediately, and I have to rebuild it after fixing the permissions problem.

Although the permissions problem needs also to be fixed, this could presumably happen if the external disk were jogged and the connection broken. It would be good to configure mpd so it did not empty a database when the music files were unavailable.

I expect that the problems described above are the same as mine, except that mpd is automatically updating when it starts, whereas I issue the update manually with mpc.
Anyway, it seems not to be a Volumio problem.

#11

A post was split to a new topic: MPD conf question: auto_update “yes” in V2, “no” in V3, why?

#12

I moved @dk31 last post to a separate topic, because it deserves higher attention