Getting MPD (Media Player Daemon) to start on reboot

[cryptotheslow]

> ian-weisser

All my upstart job seems to require is filesystem and static network up....

start on (filesystem and static-network-up)

Looking in /etc/init I can only see alsa-restore.conf and alsa-store.conf - nothing for alsa-state.

Should I add alsa-restore and alsa-store to my "start on" clause?

[ian-weisser]

Looking in /etc/init I can only see alsa-restore.conf and alsa-store.conf - nothing for alsa-state.
Should I add alsa-restore and alsa-store to my "start on" clause?

Yes, but only after the alsa config is fixed. One break at a time.

[cryptotheslow]

Yes, but only after the alsa config is fixed. One break at a time.

Eek - my alsa config is broken? Or did you mean fix the alsa section of the /etc/mpd.conf file?

As an experiment I removed myself from the audio group and tried to start mpd from the command line - I get the exact same messages about not being able to find an alsa device as I'm seing in the upstart logs.

For the furthering of my understanding... when I call sudo service mpd start that actually calls on the upstart init daemon to start mpd?
And that init daemon is running as root?
And root doesn't need to worry about group membership right?

Please correct my misunderstandings, it's the only way to learn.

I'll go and sort out the alsa section of my mpd.conf file so it works right now. As you say one thing at a time - wise words

[ian-weisser]

Eek - my alsa config is broken? Or did you mean fix the alsa section of the /etc/mpd.conf file?

Sorry for not being clear: Your big problem is getting alsa to work, regardless of how it starts. After you get it working without lots of errors in the log, then it's time to tweak the startup. Having mpd wait for alsa to start first at boot seems like a low priority.

For the furthering of my understanding... when I call sudo service mpd start that actually calls on the upstart init daemon to start mpd?
And that init daemon is running as root?
And root doesn't need to worry about group membership right?

Yes, the service command merely tells init to start/stop something.
Yes, init runs as root.
Init usually doesn't worry about groups and permissions (it has all permissions). For example, servers like MPD usually shouldn't run as root; it's a security hole. Init (as root) can start MPD (as mpd-user) without any problems or special hacking. Normal. Nothing special needed in the config file.

[cryptotheslow]

OK - fixed up the ALSA section of my /etc/mpd.conf file so it reads thus:

# An example of an ALSA output:
#
audio_output {
        type            "alsa"
        name            "Intel [HDA Intel]"
        device          "hw:0,0"        # optional
        mixer_type      "hardware"      # optional
        mixer_device    "default"       # optional
        mixer_control   "Master"        # optional
        mixer_index     "0"             # optional
}
#

And that starts up fine from a command line with mpd /etc/mpd.conf

So I killed it and tried sudo service mpd start which resulted in this /var/log/upstart/mpd.log entry:

path: SetFSCharset: fs charset is: UTF-8
db: reading DB
daemon: opening pid file
daemon: daemonized
daemon: writing pid file

And mpd is again started successfully.

And finally to see if it can start on a cold boot, I removed /var/log/mpd.log and issued an "init 0" - then powered up again,

Et voila!

crypto@ubuserver:~$ cd /var/log/upstart
crypto@ubuserver:/var/log/upstart$ ps aux | grep mpd
crypto    1058  0.7  0.2 152520  4636 ?        Ssl  04:33   0:00 mpd /etc/mpd.conf
crypto    1561  0.0  0.0   9392   932 pts/0    S+   04:34   0:00 grep --color=auto mpd
crypto@ubuserver:/var/log/upstart$ sudo cat mpd.log 
[sudo] password for crypto: 
path: SetFSCharset: fs charset is: UTF-8
db: reading DB
daemon: opening pid file
daemon: daemonized
daemon: writing pid file
crypto@ubuserver:/var/log/upstart$

SUCCESS!!!

Thank you everyone!

BUT - I still don't understand the "why?" and that annoys me to hell and back. All that I changed was to define the alsa device rather than auto-detect. Why would mpd started via the service command fail to auto-detect an alsa device when mpd run from the command line by a user succeded? grrrr


Thanks for the clarification Ian, I know it would be a bad thing for something like MPD to run as root - given that it's sat there listening for network connections. In MPD's own conf files it asks for a user to run as and it seems when it is run by upstart it forks off the process to run under that user as my ps aux shows. I'm still annoyingly puzzled about why the auto-detect for the alsa device doesn't work when called via service / init.

I swear the more I learn the more I realise I have yet to learn!

[cryptotheslow]

UGH!! I spoke too soon! MPD is starting fine but as soon as I connect a client and try to play anything I get this in the logs:

Dec 09 05:03 : decoder: audio_format=44100:24:2, seekable=true
ALSA lib pcm_hw.c:1401:(_snd_pcm_hw_open) Invalid value for card
Dec 09 05:03 : alsa_output: Failed to open "Intel [HDA Intel]" [alsa]: Failed to open ALSA device "hw:0,0": No such file or directory

My mpd.conf alsa section looks thus:

audio_output {
        type            "alsa"
        name            "Intel [HDA Intel]"
        device          "hw:0,0"        # optional
        mixer_type      "hardware"      # optional
        mixer_device    "default"       # optional
        mixer_control   "Master"        # optional
        mixer_index     "0"             # optional
}

And aplay -l looks thus:

**** List of PLAYBACK Hardware Devices ****
card 0: Intel [HDA Intel], device 0: ALC662 rev1 Analog [ALC662 rev1 Analog]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

What has a guy to do to just play some tunes around here?

[tgalati4]

I know that you don't want the overhead of pulseaudio on your server, but I have the feeling that pulseaudio has the hooks to make this work. Pulseaudio is the unified, system-wide audio framework for directing streams to audio hardware. Because you don't have it, there may be breakage for some packages that need it. In the days before pulseaudio, applications each had their own method for calling alsa and sometimes two applications would fight over the sound card. Pulseaudio fixed a lot of this with a unified audio framework--not without problems, but in general it now works pretty well.

So you can try to reinstall pulseaudio and see if that fixes your issue, or continue to chip away without it.

[cryptotheslow]

OK - I finally sorted it out by replicating a repository install type setup.

Created user "mpd" with primary group "audio", set the mpd user's home dir to /var/lib/mpd and moved all the mpd files (database, playlists etc) to there and chowned them over to mpd:audio.

Now mpd runs fine as a service with user = "mpd"

And in the process of doing that I noticed this section in the mpd.conf file....

# This setting specifies the group that MPD will run as. If not specified
# primary group of user specified with "user" setting will be used (if set).
# This is useful if MPD needs to be a member of group such as "audio" to
# have permission to use sound card.
#
# group                         ""

Sooo - a complete failure to read on my behalf, I could have just set user = "crypto" and group = "audio" all along!!! D'OH! Well I'm not changing it back now it's working