Bug#887834: [Pkg-mpd-maintainers] Bug#887834: Bug#887834: mpd installation fails, cannot open /var/lib/mpd/tag_cache, /run/mpd/pid
Hi Florian, On Fri, Nov 05, 2021 at 05:55:52AM +0100, Florian Schlichting wrote: > please, for now, delete or comment out the pid_file line Right, I saw in some other bug report that it was no longer needed or was a legacy configuration item. In that case, it should be dropped from the default /etc/mpd.conf shipped in the package: rak@zeta:/tmp$ ar p mpd_0.23.3-1_amd64.deb data.tar.xz | tar JOx ./etc/mpd.conf | grep pid_file pid_file"/run/mpd/pid" > The tag_cache exception is non-fatal. The problem here is the Assertion > failure, which is #998310 and fixed in mpd 0.23.3-2 I can confirm that 0.23.3-2 fixes this bug and that I can run mpd with the minimal mpd.conf, assuming that I delete the pid_file line. (With the pid_file line, it runs into the issue you described in the rest of your email: Nov 05 08:45:25 zeta mpd[510628]: sndfile: libsndfile-1.0.31 Nov 05 08:45:25 zeta mpd[510628]: hybrid_dsd: The Hybrid DSD decoder is disabled because it was not explicitly enabled Nov 05 08:45:25 zeta mpd[510628]: adplug: adplug 2.3.3 Nov 05 08:45:25 zeta mpd[510628]: exception: Failed to open '/var/lib/mpd/tag_cache': No such file or directory Nov 05 08:45:25 zeta mpd[510628]: curl: version 7.74.0 Nov 05 08:45:25 zeta mpd[510628]: curl: with GnuTLS/3.7.2 Nov 05 08:45:25 zeta mpd[510628]: exception: Failed to create pid file "/run/mpd/pid": Permission denied Nov 05 08:45:25 zeta systemd[1]: mpd.service: Main process exited, code=exited, status=1/FAILURE Nov 05 08:45:25 zeta systemd[1]: mpd.service: Failed with result 'exit-code'. Nov 05 08:45:25 zeta systemd[1]: Failed to start Music Player Daemon. Best, Ryan -- |)|/ Ryan Kavanagh | 4E46 9519 ED67 7734 268F |\|\ https://rak.ac | BD95 8F7B F8FC 4A11 C97A signature.asc Description: PGP signature
Bug#887834: [Pkg-mpd-maintainers] Bug#887834: Bug#887834: mpd installation fails, cannot open /var/lib/mpd/tag_cache, /run/mpd/pid
On 2021/11/05 08:09, Max Kellermann wrote: > I gave this a second thought, and I fear that changes like this one > break even more setups, which should be avoided in a stable branch. > > I'll rather revert the "RuntimeDirectory" addition for now in the > 0.23.x stable branch. And this is the result of my third thought: https://github.com/MusicPlayerDaemon/MPD/commit/a4e42172045f62583cbf97a6a94c3d2b9de77a6c This keeps RuntimeDirectory, but "fixes" the pid_file problem (by ignoring the useless pid_file setting).
Bug#887834: [Pkg-mpd-maintainers] Bug#887834: Bug#887834: mpd installation fails, cannot open /var/lib/mpd/tag_cache, /run/mpd/pid
On 2021/11/05 06:10, Max Kellermann wrote: > On 2021/11/05 05:55, Florian Schlichting wrote: > > However, Max: behind this hides another problem, which is why I asked > > Ryan to delete the pid_file configuration: as part of 0.23.3 you added > > the "RuntimeDirectory=mpd" directive to both mpd.service units. In the > > absence of User and Group directives, this causes /run/mpd to change > > ownership from mpd:audio (as created by our > > /usr/lib/tmpfiles.d/mpd.conf) to root:root, which means that mpd would > > have to be run as root in order to be able to create a socket or a > > pidfile (yes, legacy) there. I think that's broken from an upstream > > perspective as well, and only works when running mpd as user. > > True, and the real fix would be to finally cease launching MPD as > root, which is an anachronism. I gave this a second thought, and I fear that changes like this one break even more setups, which should be avoided in a stable branch. I'll rather revert the "RuntimeDirectory" addition for now in the 0.23.x stable branch. The RuntimeDirectory will be re-added to the to-become-0.24 branch, together with lots of other changes to modernize MPD with systemd (no root startup, a StateDirectory for the state file, CacheDirectory for the database file etc.)
Bug#887834: [Pkg-mpd-maintainers] Bug#887834: Bug#887834: mpd installation fails, cannot open /var/lib/mpd/tag_cache, /run/mpd/pid
On 2021/11/05 05:55, Florian Schlichting wrote: > However, Max: behind this hides another problem, which is why I asked > Ryan to delete the pid_file configuration: as part of 0.23.3 you added > the "RuntimeDirectory=mpd" directive to both mpd.service units. In the > absence of User and Group directives, this causes /run/mpd to change > ownership from mpd:audio (as created by our > /usr/lib/tmpfiles.d/mpd.conf) to root:root, which means that mpd would > have to be run as root in order to be able to create a socket or a > pidfile (yes, legacy) there. I think that's broken from an upstream > perspective as well, and only works when running mpd as user. True, and the real fix would be to finally cease launching MPD as root, which is an anachronism. > I suppose the best way forward is to specify User=mpd and Group=audio > in the system unit, however this immediately hits a snag when mpd tries > to open its log file /var/log/mpd/mpd.log, which up to now is created as > root. This we could probably work around in Debian, and defaulting to > log to syslog/journal also feels sensible, but I'm not sure if there may > be other things that mpd might want to be root for when starting up as a > system service? The right way to have a writable /var/log/mpd is "LogsDirectory=mpd", but I don't want to do that. Per-daemon log files are an anachronism, too. Just like starting daemons as root, PID files, per-daemon daemonization code and so on ... all the good stuff that systemd can do for us, stuff which in ancient times every daemon had unnecessary duplicate code for. Another thing that MPD could fail if we don't launch MPD as root is binding to "privileged ports" (another anachronism). For example, a httpd streaming output could be bound to a low port. People who do that could add a drop-in with "AmbientCapabilities=CAP_NET_BIND_SERVICE" to give MPD permission for that.
Bug#887834: [Pkg-mpd-maintainers] Bug#887834: Bug#887834: mpd installation fails, cannot open /var/lib/mpd/tag_cache, /run/mpd/pid
Hi Ryan (and Max please see below):
> and have the following minimal mpd.conf:
>
> --
> music_directory "/var/lib/mpd/music"
> db_file "/var/lib/mpd/tag_cache"
> pid_file "/run/mpd/pid"
> state_file"/var/lib/mpd/state"
> log_level "verbose"
>
> user "mpd"
> bind_to_address "127.0.0.1"
>
> audio_output {
> type "null"
> name "null"
> }
> --
please, for now, delete or comment out the pid_file line
> Attempting to start mpd results in:
>
> --
> rak@zeta:~$ sudo service mpd start
> Job for mpd.service failed because a fatal signal was delivered to the
> control process.
> See "systemctl status mpd.service" and "journalctl -xeu mpd.service" for
> details.
> rak@zeta:~$ sudo systemctl status mpd.service
> × mpd.service - Music Player Daemon
> Loaded: loaded (/usr/lib/systemd/system/mpd.service; enabled; vendor
> preset: enabled)
> Active: failed (Result: signal) since Thu 2021-11-04 13:49:36 EDT; 2s ago
> TriggeredBy: × mpd.socket
>Docs: man:mpd(1)
> man:mpd.conf(5)
> file:///usr/share/doc/mpd/html/user.html
> Process: 474546 ExecStart=/usr/bin/mpd --no-daemon $MPDCONF (code=killed,
> signal=ABRT)
>Main PID: 474546 (code=killed, signal=ABRT)
> CPU: 175ms
>
> Nov 04 13:49:36 zeta mpd[474546]: sndfile: libsndfile-1.0.31
> Nov 04 13:49:36 zeta mpd[474546]: hybrid_dsd: The Hybrid DSD decoder is
> disabled because it was not explicitly enabled
> Nov 04 13:49:36 zeta mpd[474546]: adplug: adplug 2.3.3
> Nov 04 13:49:36 zeta mpd[474546]: exception: Failed to open
> '/var/lib/mpd/tag_cache': No such file or directory
> Nov 04 13:49:36 zeta mpd[474546]: curl: version 7.74.0
> Nov 04 13:49:36 zeta mpd[474546]: curl: with GnuTLS/3.7.2
> Nov 04 13:49:36 zeta mpd[474546]: mpd: ../src/event/Loop.cxx:60:
> EventLoop::~EventLoop(): Assertion `sockets.empty()' failed.
> Nov 04 13:49:36 zeta systemd[1]: mpd.service: Main process exited,
> code=killed, status=6/ABRT
> Nov 04 13:49:36 zeta systemd[1]: mpd.service: Failed with result 'signal'.
> Nov 04 13:49:36 zeta systemd[1]: Failed to start Music Player Daemon.
The tag_cache exception is non-fatal. The problem here is the Assertion
failure, which is #998310 and fixed in mpd 0.23.3-2
However, Max: behind this hides another problem, which is why I asked
Ryan to delete the pid_file configuration: as part of 0.23.3 you added
the "RuntimeDirectory=mpd" directive to both mpd.service units. In the
absence of User and Group directives, this causes /run/mpd to change
ownership from mpd:audio (as created by our
/usr/lib/tmpfiles.d/mpd.conf) to root:root, which means that mpd would
have to be run as root in order to be able to create a socket or a
pidfile (yes, legacy) there. I think that's broken from an upstream
perspective as well, and only works when running mpd as user.
I suppose the best way forward is to specify User=mpd and Group=audio
in the system unit, however this immediately hits a snag when mpd tries
to open its log file /var/log/mpd/mpd.log, which up to now is created as
root. This we could probably work around in Debian, and defaulting to
log to syslog/journal also feels sensible, but I'm not sure if there may
be other things that mpd might want to be root for when starting up as a
system service?
Florian
