# Couple of notes on Mopidy 2.1.0 installation

**URL:** <https://discourse.mopidy.com/t/couple-of-notes-on-mopidy-2-1-0-installation/2563>\
**Category:** Misc\
**Created:** [June 8, 2018, 1:23pm UTC](https://discourse.mopidy.com/t/couple-of-notes-on-mopidy-2-1-0-installation/2563 "2018-06-08T13:23:56Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![sfgreenwood](https://yyz2.discourse-cdn.com/flex036/user_avatar/discourse.mopidy.com/sfgreenwood/32/386_2.png) [@sfgreenwood](https://discourse.mopidy.com/u/sfgreenwood)\
**Post date:** [June 8, 2018, 1:23pm UTC](https://discourse.mopidy.com/t/couple-of-notes-on-mopidy-2-1-0-installation/2563/1 "2018-06-08T13:23:57Z")

</div>

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`.

---

<div class="post-metadata">

**Author:** ![kingosticks](https://avatars.discourse-cdn.com/v4/letter/k/858c86/32.png) [@kingosticks](https://discourse.mopidy.com/u/kingosticks)\
**Post date:** [June 8, 2018, 2:13pm UTC](https://discourse.mopidy.com/t/couple-of-notes-on-mopidy-2-1-0-installation/2563/2 "2018-06-08T14:13:46Z")

</div>

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`:

```auto
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](https://sources.debian.org/src/mopidy/2.1.0-2/debian/mopidy.postinst/#L21-L25).

> [@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](https://docs.mopidy.com/en/latest/service/#service-management-with-systemd).

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

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

```

Am I misunderstanding?

---

<div class="post-metadata">

**Author:** ![sfgreenwood](https://yyz2.discourse-cdn.com/flex036/user_avatar/discourse.mopidy.com/sfgreenwood/32/386_2.png) [@sfgreenwood](https://discourse.mopidy.com/u/sfgreenwood)\
**Post date:** [June 8, 2018, 3:06pm UTC](https://discourse.mopidy.com/t/couple-of-notes-on-mopidy-2-1-0-installation/2563/3 "2018-06-08T15:06:38Z")

</div>

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`:
> 
> ```auto
> 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](https://sources.debian.org/src/mopidy/2.1.0-2/debian/mopidy.postinst/#L21-L25).

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](https://docs.mopidy.com/en/latest/service/#service-management-with-systemd).

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

```auto
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.