MPD can no longer start, because it can't find its conf file:
#mpd
exception: No configuration file found
/etc/mpd.conf is in place
/lib/systemd/system/mpd.service has some conflicting info. Note that it's forcing the binary to see /etc/mpd.conf but ALSO is telling it to look in /etc/default/mpd (which has its own configuration about where to put the conf file). Also, I think that those directories in /var/run/mpd maybe shouldn't be messed with every time... since the service here claims that mpd will change its user in a fork, but the chown might wreck that.
[Unit]
Description=Music Player Daemon
After=network.target sound.target
[Service]
#User=root #forks its own process under user set in /etc/mpd.conf (mpd)
Type=simple
LimitRTPRIO=infinity
RuntimeDirectory=/var/run/mpd
EnvironmentFile=/etc/default/mpd
ExecStartPre=/bin/mkdir -p /var/run/mpd
ExecStartPre=/bin/chown -R root:dietpi /var/run/mpd
ExecStart=/usr/local/bin/mpd --no-daemon /etc/mpd.conf
[Install]
WantedBy=multi-user.target
Here's /etc/default/mpd:
#Even though we declare the conf location in our service, MPD will fail to start if this file does not exist.
## The configuration file location for mpd:
MPDCONF=/etc/mpd.conf
But anyway, if you ignore the systemctl version and just try and run it, it still doesn't work:
# /usr/local/bin/mpd
exception: No configuration file found
#!/bin/bash
G_DIETPI_VERSION_CORE=6
G_DIETPI_VERSION_SUB=19
G_DIETPI_VERSION_RC=7
G_GITBRANCH=master
G_GITOWNER=Fourdee
9.6Linux PiFi 3.10.38 #22 SMP PREEMPT Fri Dec 22 10:45:41 IST 2017 armv7l GNU/LinuxSparky SBC (armv7l)See above.
So there are some weird things going on. First, if one forces mpd to use /etc/mpd.conf it DOES find it. If you just run it, it doesn't, though the file is there, and so on.
@mfeif
Thanks for your report.
/lib/systemd/system/mpd.service has some conflicting info. Note that it's forcing the binary to see /etc/mpd.conf but ALSO is telling it to look in /etc/default/mpd (which has its own configuration about where to put the conf file).
Jep indeed this is somehow confusing. However the comment in /etc/default/mpd states that it is meant to be like that. I will just retry if really the environment file is required, if EnvironmentFile=/etc/default/mpd is removed from systemd unit as well.
Also, I think that those directories in /var/run/mpd maybe shouldn't be messed with every time... since the service here claims that mpd will change its user in a fork, but the chown might wreck that.
This is only a failsafe thing and should not break anything, since only group is changed. Actually all this should be not required. PID files and runtime dirs are created automatically by systemd and since the service runs as root, there should be no access issues at all. Even if sub processes spawn as different users, those should not require access to the runtime dir.
Perhaps I find some time to clean the above up, however as I am not sure about the reasons and done testing, there might be reasons for it, so intense testing is required which take much time. And since it should not cause any issues...
# /usr/local/bin/mpd
exception: No configuration file found
~Note that the configuration file is a non optional argument of the mpd command:~
€: Ah it's not, working without given config file on default Debian repo install!
root@VM-Stretch:~# mpd --help
Usage:
mpd [OPTION...] [path/to/mpd.conf]
Music Player Daemon - a daemon for playing music.
Options:
-h, --help show help options
--kill kill the currently running mpd session
--no-config don't read from config
--no-daemon don't detach from console
--stderr print messages to stderr
-v, --verbose verbose logging
-V, --version print version number
/usr/local/bin/mpd /etc/mpd.conf instead or simply: mpd /etc/mpd.confActually no issue here with removing /etc/default/mpd and EnvironmentFile= in systemd unit.
It is possible to use the default Stretch systemd unit with additional hardenings, only binary needs to be adjusted to /usr/local/bin:
[Unit]
Description=Music Player Daemon
After=network.target sound.target
[Service]
EnvironmentFile=/etc/default/mpd
ExecStart=/usr/local/bin/mpd --no-daemon $MPDCONF
# allow MPD to use real-time priority 50
LimitRTPRIO=50
LimitRTTIME=infinity
# disallow writing to /usr, /bin, /sbin, ...
ProtectSystem=yes
# more paranoid security settings
NoNewPrivileges=yes
ProtectKernelTunables=yes
ProtectControlGroups=yes
ProtectKernelModules=yes
# AF_NETLINK is required by libsmbclient, or it will exit() .. *sigh*
RestrictAddressFamilies=AF_INET AF_INET6 AF_UNIX AF_NETLINK
RestrictNamespaces=yes
[Install]
WantedBy=multi-user.target
Also=mpd.socket
Ah and RuntimeDirectory NEEDS to be pre-created and chowned to run user defined in /etc/mpd.conf. The default Debian repo install creates it with mpd:audio owner. However on DietPi it would be good, if mpd could access files within /mnt/dietpi_userdata so should be in dietpi group. And to be failsafe it makes sense to pre-create and chown the runtime dir with this just on service start.
Only thing:
Testing above config file on Jessie:
Dec 29 22:22:03 VM-Jessie systemd[1]: [/lib/systemd/system/mpd.service:21] Unknown lvalue 'ProtectKernelTunables' in section 'Service'
Dec 29 22:22:03 VM-Jessie systemd[1]: [/lib/systemd/system/mpd.service:22] Unknown lvalue 'ProtectControlGroups' in section 'Service'
Dec 29 22:22:03 VM-Jessie systemd[1]: [/lib/systemd/system/mpd.service:23] Unknown lvalue 'ProtectKernelModules' in section 'Service'
Dec 29 22:22:03 VM-Jessie systemd[1]: [/lib/systemd/system/mpd.service:26] Unknown lvalue 'RestrictNamespaces' in section 'Service'
Dec 29 22:22:05 VM-Jessie systemd[1]: Starting Music Player Daemon...
Dec 29 22:22:06 VM-Jessie systemd[1]: Started Music Player Daemon.
I opened a PR to address the above: https://github.com/Fourdee/DietPi/pull/2381
I have not yet a clue, why on default Debian package install, the "mpd" command finds the config file automatically and when our manually compiled package is installed, it does not.
Perhaps this is also something that can be set/changed when compiling?
@MichaIng
- DietPi-Software | MPD: Now runs under the group 'dietpi' and user 'root', allowing access to music directories when contained on samba networked drives: https://github.com/Fourdee/DietPi/issues/2092
@Fourdee
Jep, I also found that. However dietpi group should be now sufficient since we mount samba drives as dietpi group now with 77X permissions?
mount -t cifs -o username="$samba_clientuser",password="$samba_clientpassword",uid=dietpi,gid=dietpi,file_mode=0770,dir_mode=0770...
@mfeif @Fourdee
I found the reason for the file-not-found error:
mpd on Jessie is a custom build, it is installed to /usr/local/bin and from there by default looks into /usr/local/etc/mpd.conf instead of /etc/mpd.conf.mpd.conf one could call it design issue, that /etc is skipped for custom builds:mpd.conf is the configuration file for mpd(1). If not specified on the command line, MPD first searches for it at $XDG_CONFIG_HOME/mpd/mpd.conf then at ~/.mpdconf then at ~/.mpd/mpd.conf and then in /etc/mpd.conf.
To resolve:
mkdir -p /usr/local/etc
ln -sf /etc/mpd.conf /usr/local/etc/mpd.conf
Fixed with: https://github.com/Fourdee/DietPi/pull/2381/commits/10efc0667755eb2bef5ca736432177637569156e
Changelog: https://github.com/Fourdee/DietPi/pull/2381/commits/ac7c477c5ac6b463d741551376dfc87520b532bd
Nice work guys! Thanks!
Most helpful comment
@mfeif @Fourdee
I found the reason for the file-not-found error:
mpdon Jessie is a custom build, it is installed to/usr/local/binand from there by default looks into/usr/local/etc/mpd.confinstead of/etc/mpd.conf.mpd.confone could call it design issue, that/etcis skipped for custom builds:To resolve:
Fixed with: https://github.com/Fourdee/DietPi/pull/2381/commits/10efc0667755eb2bef5ca736432177637569156e
Changelog: https://github.com/Fourdee/DietPi/pull/2381/commits/ac7c477c5ac6b463d741551376dfc87520b532bd