FS#42089 - [mpd][ffmpeg] update results in no play sound

Attached to Project: Arch Linux
Opened by Bogomil (smirky) - Tuesday, 23 September 2014, 15:32 GMT
Last edited by Gaetan Bisson (vesath) - Saturday, 25 April 2015, 21:09 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Gaetan Bisson (vesath)
Architecture x86_64
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 7
Private No

Details

Description:
Since today's updates of mpd and ffmpeg, there's no sound going through the local play. After downgrading mpd from 0.18.14-2 to 0.18.14-1 and ffmpeg from 1:2.4.1-1 to 1:2.3.3-2, the problem is gone.

Additional info:
ffmpeg 1:2.4.1-1
mpd 0.18.14-2

Steps to reproduce:

Update to latest mpd and ffmpeg builds.
This task depends upon

Closed by  Gaetan Bisson (vesath)
Saturday, 25 April 2015, 21:09 GMT
Reason for closing:  Works for me
Comment by Gaetan Bisson (vesath) - Tuesday, 23 September 2014, 20:16 GMT
My logs say this:

Sep 23 10:14:01 kujira systemd[1]: Started Music Player Daemon.
Sep 23 10:14:01 kujira mpd[675]: server_socket: bind to '0.0.0.0:6600' failed: Address already in use (continuing anyway, because binding to '[::]:6600' succeeded)
Sep 23 10:14:01 kujira mpd[675]: output: No 'audio_output' defined in config file
Sep 23 10:14:01 kujira mpd[675]: output: Attempt to detect audio output device
Sep 23 10:14:01 kujira mpd[675]: output: Attempting to detect a alsa audio device
Sep 23 10:14:01 kujira mpd[675]: ALSA lib confmisc.c:768:(parse_card) cannot find card '1'
Sep 23 10:14:01 kujira mpd[675]: ALSA lib conf.c:4259:(_snd_config_evaluate) function snd_func_card_driver returned error: No such file or directory
Sep 23 10:14:01 kujira mpd[675]: ALSA lib confmisc.c:392:(snd_func_concat) error evaluating strings
Sep 23 10:14:01 kujira mpd[675]: ALSA lib conf.c:4259:(_snd_config_evaluate) function snd_func_concat returned error: No such file or directory
Sep 23 10:14:01 kujira mpd[675]: ALSA lib confmisc.c:1251:(snd_func_refer) error evaluating name
Sep 23 10:14:01 kujira mpd[675]: ALSA lib conf.c:4259:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory
Sep 23 10:14:01 kujira mpd[675]: ALSA lib conf.c:4738:(snd_config_expand) Evaluate error: No such file or directory
Sep 23 10:14:01 kujira mpd[675]: ALSA lib pcm.c:2239:(snd_pcm_open_noupdate) Unknown PCM default
Sep 23 10:14:01 kujira mpd[675]: alsa_output: Error opening default ALSA device: No such file or directory
Sep 23 10:14:01 kujira mpd[675]: output: Attempting to detect a oss audio device
Sep 23 10:14:01 kujira mpd[675]: oss_output: Error opening OSS device "/dev/dsp": No such file or directory
Sep 23 10:14:01 kujira mpd[675]: oss_output: Error opening OSS device "/dev/sound/dsp": No such file or directory
Sep 23 10:14:01 kujira mpd[675]: output: Attempting to detect a pulse audio device
Sep 23 10:14:01 kujira systemd[1]: mpd.service: main process exited, code=killed, status=6/ABRT
Sep 23 10:14:01 kujira systemd[1]: Unit mpd.service entered failed state.
Sep 23 10:14:01 kujira mpd[675]: Assertion 'm' failed at pulse/thread-mainloop.c:236, function pa_threaded_mainloop_get_api(). Aborting.
Comment by Gaetan Bisson (vesath) - Tuesday, 23 September 2014, 20:18 GMT
Adding the following to /etc/mpd.conf fixes the issue:

audio_output {
type "alsa"
name "card"
}
Comment by Gaetan Bisson (vesath) - Tuesday, 23 September 2014, 20:19 GMT
Ah, not really, it still cannot play, but at least it runs...
Comment by Gaetan Bisson (vesath) - Tuesday, 23 September 2014, 20:20 GMT
The logs show the error:

Sep 23 10:20:36 kujira mpd[1359]: alsa_mixer: Failed to read mixer for 'PCH [HDA Intel PCH]': failed to attach to default: No such file or directory
Comment by Bogomil (smirky) - Tuesday, 23 September 2014, 20:24 GMT
I don't have problems running it. Systemctl doesn't spill any errors here. Still, there is no sound.
My conf:
Comment by Bogomil (smirky) - Tuesday, 23 September 2014, 20:26 GMT
Hm... I found this in mpd.log

Sep 23 18:25 : alsa_output: Failed to open "internal" [alsa]: Failed to open ALSA device "plug:dmix": No such file or directory
ALSA lib confmisc.c:768:(parse_card) cannot find card '0'
ALSA lib conf.c:4259:(_snd_config_evaluate) function snd_func_card_driver returned error: No such file or directory
ALSA lib confmisc.c:392:(snd_func_concat) error evaluating strings
ALSA lib conf.c:4259:(_snd_config_evaluate) function snd_func_concat returned error: No such file or directory
ALSA lib confmisc.c:1251:(snd_func_refer) error evaluating name
ALSA lib conf.c:4259:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory
ALSA lib conf.c:4738:(snd_config_expand) Evaluate error: No such file or directory
ALSA lib pcm.c:2239:(snd_pcm_open_noupdate) Unknown PCM dmix
Comment by Gaetan Bisson (vesath) - Wednesday, 24 September 2014, 01:35 GMT
Your mpd.conf is heavily customized. For now I prefer to focus on debugging why our minimal default settings do not work. Any help is welcome, though!
Comment by Gaetan Bisson (vesath) - Wednesday, 24 September 2014, 01:53 GMT
It appears running `/usr/bin/mpd --no-daemon` as root gives me a working MPD daemon, while running it through systemd systematically fails. Could you confirm if this fixes your issue?
Comment by Gaetan Bisson (vesath) - Wednesday, 24 September 2014, 02:03 GMT
Just to summarize: with a vanilla mpd-0.18.14-2 from Arch repos and an uncustomized configuration, I get

$ systemctl start mpd
$ systemctl status mpd -n 30
● mpd.service - Music Player Daemon
Loaded: loaded (/usr/lib/systemd/system/mpd.service; enabled)
Active: failed (Result: signal) since Tue 2014-09-23 15:58:47 TAHT; 4min 5s ago
Process: 30222 ExecStart=/usr/bin/mpd --no-daemon (code=killed, signal=ABRT)
Main PID: 30222 (code=killed, signal=ABRT)

Sep 23 15:58:47 aji systemd[1]: Started Music Player Daemon.
Sep 23 15:58:47 aji mpd[30222]: server_socket: bind to '0.0.0.0:6600' failed: Address already in use (continuing anyway, because binding to '[::]:6600' succeeded)
Sep 23 15:58:47 aji mpd[30222]: output: No 'audio_output' defined in config file
Sep 23 15:58:47 aji mpd[30222]: output: Attempt to detect audio output device
Sep 23 15:58:47 aji mpd[30222]: output: Attempting to detect a alsa audio device
Sep 23 15:58:47 aji mpd[30222]: ALSA lib confmisc.c:768:(parse_card) cannot find card '0'
Sep 23 15:58:47 aji mpd[30222]: ALSA lib conf.c:4259:(_snd_config_evaluate) function snd_func_card_driver returned error: No such file or directory
Sep 23 15:58:47 aji mpd[30222]: ALSA lib confmisc.c:392:(snd_func_concat) error evaluating strings
Sep 23 15:58:47 aji mpd[30222]: ALSA lib conf.c:4259:(_snd_config_evaluate) function snd_func_concat returned error: No such file or directory
Sep 23 15:58:47 aji mpd[30222]: ALSA lib confmisc.c:1251:(snd_func_refer) error evaluating name
Sep 23 15:58:47 aji mpd[30222]: ALSA lib conf.c:4259:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory
Sep 23 15:58:47 aji mpd[30222]: ALSA lib conf.c:4738:(snd_config_expand) Evaluate error: No such file or directory
Sep 23 15:58:47 aji mpd[30222]: ALSA lib pcm.c:2239:(snd_pcm_open_noupdate) Unknown PCM default
Sep 23 15:58:47 aji mpd[30222]: alsa_output: Error opening default ALSA device: No such file or directory
Sep 23 15:58:47 aji mpd[30222]: output: Attempting to detect a oss audio device
Sep 23 15:58:47 aji mpd[30222]: oss_output: Error opening OSS device "/dev/dsp": No such file or directory
Sep 23 15:58:47 aji mpd[30222]: oss_output: Error opening OSS device "/dev/sound/dsp": No such file or directory
Sep 23 15:58:47 aji mpd[30222]: output: Attempting to detect a pulse audio device
Sep 23 15:58:47 aji mpd[30222]: Assertion 'm' failed at pulse/thread-mainloop.c:236, function pa_threaded_mainloop_get_api(). Aborting.
Sep 23 15:58:47 aji systemd[1]: mpd.service: main process exited, code=killed, status=6/ABRT
Sep 23 15:58:47 aji systemd[1]: Unit mpd.service entered failed state.

However, the following works just fine:

$ /usr/bin/mpd --no-daemon
server_socket: bind to '0.0.0.0:6600' failed: Address already in use (continuing anyway, because binding to '[::]:6600' succeeded)
output: No 'audio_output' defined in config file
output: Attempt to detect audio output device
output: Attempting to detect a alsa audio device
output: Successfully detected a alsa audio device
Comment by Ryan (tuborg) - Wednesday, 24 September 2014, 02:22 GMT
Adding "User=mpd" under "[Service]" in /usr/lib/systemd/system/mpd.service fixed it here. My /etc/mpd.conf has `user "mpd"` which is in the default config.

Without that mpd would complain about the audio_output alsa settings:
ALSA lib conf.c:4705:(snd_config_expand) Unknown parameters CARD=SB,DEV=0
ALSA lib pcm.c:2239:(snd_pcm_open_noupdate) Unknown PCM iec958:CARD=SB,DEV=0

Edit: This makes the mpd.conf user setting redundant/conflicting now.
Comment by Christian Hesse (eworm) - Wednesday, 24 September 2014, 09:10 GMT
I can confirm that solution by Ryan (tuborg) works. Looks like mpd can not access alsa device files after it dropped privileges from root to user mpd. No idea what systemd does here...

However I think moving the user setting to systemd unit file makes sense. That way mpd is not startet with root privileges at all.
Comment by Christian Hesse (eworm) - Wednesday, 24 September 2014, 09:21 GMT
Something like this...
   mpd.conf (1.3 KiB)
Comment by Bogomil (smirky) - Wednesday, 24 September 2014, 12:04 GMT
I confirm that adding User=mpd in the mpd.service fixes the issue. Also I had to change the permissions to my mpd.conf:

Sep 24 14:55:18 archy mpd[28759]: errno: Failed to open /etc/mpd.conf: Permission denied

OLD: -rw------- 1 root mpd 1672 Sep 23 23:34 mpd.conf
NEW: -rw-r--r-- 1 root mpd 1672 Sep 23 23:34 mpd.conf

$ chown root.root /etc/mpd.conf
This also works (mpd group not required).

And I also had to rm /var/log/mpd/mpd.log because of permissions again:

Sep 24 14:58:19 archy mpd[29313]: errno: failed to open log file "/var/log/mpd/mpd.log" (config line 5): Permission denied

I could have changed them but I preferred a new log. Everything works fine so far.
Comment by Bogomil (smirky) - Wednesday, 24 September 2014, 12:08 GMT
Anyway, this is only a workaround and you should be able to specify the user from the conf, not the .service file.
Comment by Christian Hesse (eworm) - Wednesday, 24 September 2014, 12:12 GMT
I think it is a good idea to put the user setting into systemd service file. mpd could be vulnerable to a security problem before it drops privileges. You do not have that problem when mpd is started with a different user (with low privileges) by systemd.
Comment by Gaetan Bisson (vesath) - Wednesday, 24 September 2014, 17:30 GMT
Thanks a lot for your help everyone!
Comment by Wieland Hoffmann (Mineo) - Thursday, 23 April 2015, 16:34 GMT
  • Field changed: Percent Complete (100% → 0%)
It looks like the solution to this bug has been to carry a patch breaking
behaviour that's documented to work by upstream (the "user" and "group" options
are documented in both mpd.conf(5), as well as
/usr/share/doc/mpd/mpdconf.example which is referenced by /etc/mpd.conf). This
change in behaviour is not documented anywhere (unless you explicitly read the
PKGBUILD or the bugtracker). Both https://bugs.archlinux.org/task/42172 and
https://bugs.archlinux.org/task/44571 show that this results in error messages
that are not really helpful.

It also looks like the bug this ticket is about has not been reported upstream,
which means this undocumented divergence from upstream behaviour will forever be
part of the mpd package in Arch Linux.

If carrying patches breaking upstream behaviour indefinitely is now part of Arch
Linux' packaging rules, I'd encourage also patching the manpages and example
config files to clearly state which changes have been made, how they make the
package differ from the upstream version and how the desired effect (changing
the user and/or group MPD is running as) can be achieved on Arch.
Comment by Gaetan Bisson (vesath) - Thursday, 23 April 2015, 19:11 GMT
Wow. By "patching" you mean us just adding a User= directive to the service file? Our only change here is to rely on systemd's ability to start unprivileged daemons instead of mpd's ability to drop privileges. From a security standpoint, that is clearly the best way; from a stability standpoint, as this bug shows, this also yields benefits. I agree with you that we should avoid customizing upstream's configuration and service files whenever possible, and that this issue should have been reported upstream, but this certainly does not warrant the harshness of your comment. Now, to move things forward, could you bring this issue upstream and/or suggest another, better way to fix it? Thanks.
Comment by Wieland Hoffmann (Mineo) - Friday, 24 April 2015, 07:20 GMT
I apologize if my comment came across as harsh - it was certainly not meant to be, I was merely trying to point out why I think this ticket should be reopened, even after two other tickets complaining about the behaviour that's a result of this ticket have been closed as not being a bug.

Yes, not knowing a better word, I used "patching" - if there is a better one, I'd be glad to learn it.

I could report the bug upstream, if I knew how to reproduce it - the logs in this ticket contain messages about ALSA (one about dmix as well, others not...), assertion failures in some Pulseaudio file of MPD and OSS and there are apparently some permissions on the config file that need to match. Before I rip my configuration apart completely, I'd love to know how a configuration that made MPD not work a few months ago should look like (but in that case, you could just report it upstream yourselves because you already did all the work :-) ).
Comment by Gaetan Bisson (vesath) - Saturday, 25 April 2015, 21:09 GMT
Sadly I forgot everything about this bug report when I closed it down as "fixed". I suggest removing the User= directive from our service file, restoring the user setting in mpd.conf and seeing if anything goes wrong with the most recent mpd release. Please file a bug report upstream with your findings and/or a new bug report in Arch if you find any feature does not work properly.

Loading...