The current mpd rc-script doesn't wait for the daemon to fully start; instead it waits just an arbitrary amount of time and then assumes the daemon is accessible even though it might not yet be ready to handle incoming connections. This is a problem with other services which might depend on it, like mpdas, which crash at boot if they cannot connect to mpd at startup. Reproducible: Always Steps to Reproduce: 1. Have a slow computer. 2. Install mpd and mpdas, and enable both to start at boot. 3. Reboot Actual Results: # service mpdas status * status: crashed Expected Results: # service mpdas status * status: started Currently, the start() function in /etc/init.d/mpd uses the daemonization feature provided by start-stop-daemon wrapper (and explicitly disables the functionality built into mpd): start-stop-daemon --start --quiet --background --wait 50 --exec /usr/bin/mpd --pidfile /var/run/mpd.pid --make-pidfile -- --no-daemon /etc/mpd.conf 2>/dev/null Unfortunately, the first time mpd is started, it needs more than 50 milliseconds to start, and as a consequence, the mpdas service which depends on it will crash because it fails to connect to the not-yet-available mpd service. (The issue may be a bit tricky to reproduce because of the timing involved -- I only see the problem on a cold start.) To fix the problem locally, I changed the rc script to start mpd in the foreground, allowing it to create its own pidfile and letting it daemonize itself when it's ready. To do this, I enabled pidfile creation in /etc/mpd.conf: pid_file "/var/lib/mpd/pid" And I changed /etc/init.d/mpd: start() { ... start-stop-daemon --start --exec /usr/bin/mpd --pidfile /var/lib/mpd/pid -- /etc/mpd.conf .... } stop() { .... start-stop-daemon --stop --exec /usr/bin/mpd --pidfile /var/lib/mpd/pid ..... } Note that the pid file goes in /var/lib/mpd because mpd changes its uid to "mpd" (or whatever user is configured in /etc/mpd.conf) before creating the pid file, and therefore doesn't have sufficient permissions to create it in /run (which is owned by root). Perhaps this could be worked around by pre-creating /run/mpd.pid with the appropriate permissions in the rc-script. Fundamentally, I think this approach (letting mpd daemonize) is better because it allows mpd to determine when it is time to exit the foreground process rather than waiting for an arbitrary period of time which may be too long or too short depending on circumstances. The fact that mpd takes the path to the PID file from /etc/mpd.conf instead of the command line, might prevent the package maintainers from making this approach the default. However, I thought I should describe this solution here, so people who run into the same problem have at least one reasonable fix available.
media-sound/mpdas doesn't require a local MPD.
(In reply to Maks Verver from comment #0) > The fact that mpd takes the path to the PID file from /etc/mpd.conf instead > of the command line, might prevent the package maintainers from making this > approach the default. However, I thought I should describe this solution > here, so people who run into the same problem have at least one reasonable > fix available. That's exactly the reason I didn't change this yet. Although I've been thinking about changing the init script and will probably do so but instead use mpd --kill to stop mpd instead of s-s-d --stop. The init script actually worked similar to that in the past, I'm not sure why I changed it back then.
+ 15 Apr 2014; Christoph Mende <angelos@gentoo.org> +files/mpd-0.18.conf.patch, + +files/mpd2.init, +mpd-0.18.10-r1.ebuild: + Change init script to use mpd's own forking mechanism (bug #507734)
