Couple of notes on Mopidy 2.1.0 installation

[sfgreenwood]

I run Mopidy as a headless client for Subsonic using subidy and beets on Raspberry Pi 3s. As I have a few of these and I’m teaching myself ansible I thought I would write a playbook for this using the Debian repo and a manual install for subidy.
I discovered that installing this way on Raspbian stretch works but throws up a couple of interesting issues.
To get a working config, run mopidy config > mopidy.conf which will give you the components you need to customise. Then copy that to /etc/mopidy/mopidy.conf. Ensure that this file is readable by issuing sudo chmod 644 /etc/mopidy/mopidy.conf - by default the file is installed 640 and can’t be read by the systemctl ExecStart command as mopidy
It also seems that the installed service file isn’t the one that is being read so to be sure, run systemctl enable mopidy to enable the installed service.
For some reason I also end up with mopidy installed in /usr/bin and /usr/local/bin and it took me quite a while to work out why the systemctl script wasn’t acknowledging my config - the default, which may come from pip, calls the launcher in /usr/local/bin.

[kingosticks]

Hi, thanks for your efforts to improve Mopidy, appreciated. I’m not sure I understand some of your issues and I think our docs already cover the rest.

@sfgreenwood

To get a working config, run mopidy config > mopidy.conf which will give you the components you need to customise

This generally isn’t a good idea:

@https://docs.mopidy.com/en/latest/config/

If you want to keep the default for a config value, you should not add it to the config file, but leave it out so that when we change the default value in a future version, you won’t have to change your configuration accordingly.

@sfgreenwood

Ensure that this file is readable by issuing sudo chmod 644 /etc/mopidy/mopidy.conf - by default the file is installed 640 and can’t be read by the systemctl ExecStart command as mopidy

The debian package ensures /etc/mopidy/mopidy.conf owned by mopidy:

chown mopidy:root /etc/mopidy/mopidy.conf
chmod 640 /etc/mopidy/mopidy.conf

So that systemctl running as user mopidy should have no problem reading it. It is explicitly not world-readable since mopidy.conf may contain passwords and other confidential information.

@sfgreenwood

It also seems that the installed service file isn’t the one that is being read

I don’t follow. Our docs do explain how to enable the service.

The systemd unit explicitly runs /usr/bin/mopidy and explicitly reads /etc/mopidy/mopidy.conf:

ExecStart=/usr/bin/mopidy --config /usr/share/mopidy/conf.d:/etc/mopidy/mopidy.conf

Am I misunderstanding?

[sfgreenwood]

This generally isn’t a good idea:

@https://docs.mopidy.com/en/latest/config/

If you want to keep the default for a config value, you should not add it to the config file, but leave it out so that when we change the default value in a future version, you won’t have to change your configuration accordingly.

Of course, understood.

@sfgreenwood

Ensure that this file is readable by issuing sudo chmod 644 /etc/mopidy/mopidy.conf - by default the file is installed 640 and can’t be read by the systemctl ExecStart command as mopidy

The debian package ensures /etc/mopidy/mopidy.conf owned by mopidy:

chown mopidy:root /etc/mopidy/mopidy.conf
chmod 640 /etc/mopidy/mopidy.conf

So that systemctl running as user mopidy should have no problem reading it. It is explicitly not world-readable since mopidy.conf may contain passwords and other confidential information.

Understood, that was my mistake and it occurred to me while I was writing this post. I am copying an existing config which I have been running for a while. I was looking at the directory and logging.conf is root:root and 644 so I made mopidy.conf the same. Must RTFM.

@sfgreenwood

It also seems that the installed service file isn’t the one that is being read

I don’t follow. Our docs do explain how to enable the service.

The systemd unit explicitly runs /usr/bin/mopidy and explicitly reads /etc/mopidy/mopidy.conf:

ExecStart=/usr/bin/mopidy --config /usr/share/mopidy/conf.d:/etc/mopidy/mopidy.conf

Am I misunderstanding?
[/quote]

I’m not sure what was happening - it seemed that without running sudo systemctl enable mopidy first, systemctl worked but didn’t pick up the config in /etc/mopidy. Then again it could be because I was trying to import an existing config file and messed up the permissions.