Running Mopidy as a daemon in Debian

[tkem]

Hi y'all,

I forked the "debian" branch and added a small Debian package for running Mopidy as a system daemon.

The additional package is named "mopidy-daemon", depends on the "mopidy" package (so I could use the current version from the repo), and provides:

• a system user "mopidy" in group "audio" with home /var/lib/mopidy
• directories /var/cache/mopidy, /var/lib/mopidy/media, /var/lib/mopidy/playlists, /var/lib/mopidy/log
• an init script /etc/init.d/mopidy-daemon
• default configuration for init script in /etc/default/mopidy-daemon
• minimum default configuration in /etc/mopidy/mopidy.conf, with setup for local music/playlists in /var/lib/mopidy/{media,playlists}
• separate logging configuration in /etc/mopidy/logging.conf, with log output directed to /var/log/mopidy/mopidy.log
• running "/etc/init.d/mopidy-daemon force-reload" invokes mopidy-scan
• except for adding the new package to debian/control, no interference with existing code

I'd greatly appreciate if you gave this a look, and let me know what you think of it. I've tested on Ubuntu 13.10 and Raspbian. My primary goal for this was to replace MPD on my Raspberry Pi "kitchen radio"; looks good, so far ;-)

Kind Regards,
Thomas

[jodal]

Cool! I'll give this a look later :-)

[adamcik]

Great idea splitting out the daemon config from the main server like this :-)

[tkem]

Well, thanks ;-) The idea was to keep the whole daemon-thing self-contained, and keep the standard mopidy package as-is. A lot of people seem to have invested quite some effort to get mopidy running as a daemon locally, so they might not want to install the daemon package, since that would clash with their "homegrown" installation.

One area that needs some clarification, though, is the use of /etc/mopidy/mopidy.conf

My version of mopidy does not seem to use it when running locally, but mopidy-scan does, according to debug output. It would also be great if mopidy-scan had a --config option, so I could use that when running it from the init script on "force-reload".

[adamcik]

mopidy-scan is being moved to a sub-command of mopidy, this means that the behavior is unified with respect to --config

[adamcik]

Hmm, this idea is probably something that doesn't need to fit into this initial PR, but we probably want a /etc/mopidy/extensions.d/{spotify,soundcloud,...}.conf as we need to be able to let the other debian packages such as mopidy-spotify install config files as well. So this would basically end up setting --config to first all the .d files and finally /etc/mopidy/mopidy.conf

[tkem]

Having a separate directory for extensions is definitely a good idea; the way this is generally done is having a setting in your master config file, e.g.

config_dir = /etc/mopidy/extensions.d

or

config_files = /etc/mopidy/extensions.d/*.conf

so the files will usually be included after parsing your master config.

So this could be implemented later without any change to --config behavior.

[tkem]

Sorry, make this include_dir or include_files for clearer semantics.

[adamcik]

I'll have to think a bit about how I want to solve this, was happy with just having gotten rid of loading the config in two phases. But not really a huge deal if we re-add it.

Alternative I'm considering is a flag for the same thing, and have it default to $XDG_CONFIG_DIRS and search for mopidy/*conf, or just have --config-include-dir=...

But I digress again, this is useful to figure out, but not relevant mergin for this PR. Hopefully @jodal will have some time soon to look at the packaging changes :-)

[jodal]

Please do s/=/ = /g for increased readability here as it's an ini file, not a shell script.

[jodal]

I think this looks really good!

I will want to include this in the mopidy package and not as a separate package. That's whats makes sense when getting Mopidy into Debian. All the people having various init script setups will probably be happy with a way more complete and maintained init script setup.

That said, please continue to keep the packages separated for now, and I'll merge them later, but name variables etc with the mopidy package in mind, e.g. drop "daemon" from most places.

[tfheen]

This file can be completely dropped since it only contains the debhelper token.

[tkem]

I thought this was necessary for a prerm script with a proper stop command to be generated, but this seems to be handled by dh_installinit anyway. Thanks for the hint.

[jodal]

@gitkemmer For some much needed context, @tfheen is the Debian Developer that will sponsor the Mopidy packages into Debian. Consider his words my words :-)

[tkem]

Yeah, I know: Always be nice to your Debian sponsor ;-)

[tkem]

@jodal, so it doesn't get lost in the commit comments: @tfheen suggested removing the .default file altogether, since there's no real reasing for overriding these settings for an end user/admin,

The .default was convenient to get this up and running, but since this stuff may now be included in the official mopidy package, I'd be happy to get rid of it.

Can we agree on this? We'd have to clarify the default options (currently --quiet), though.

[jodal]

I'm all good with removing the *.default file.

I think having --quiet in the default args makes lots of sense when we're running as a daemon. We want logging to file, not to stdout.

[tfheen]

With proper init systems (cough systemd cough), logging to stdout is fine, but you can have that difference if you start shipping a .service file. :-)

[tkem]

Hi all,
I think I now made most of the changes suggested by @jodal and @tfheen; stubbornly refused to rename $DAEMON_USER to $USER, though ;-)
I also rebased this on the current 0.17.0 debian branch and converted the init-script "force-reload" option to run mopidy local scan sub-command.
Please have another look.

[tkem]

@tfheen: for now, the "mopidy-daemon" package is kept separate, as is the init script; @jodal will merge this into the regular "mopidy" package at his convenience. This will also include renaming "mopidy-daemon.init" to "mopidy.init", I guess.

The "- documentation" was an oversight, of course. Thanks for reporting!

[tfheen]

Renaming init scripts is a pain, I'd recommend changing the init script name straight away even if you keep the init script in its own package.

[jodal]

I've merged (and squashed) this into the debian branch now, tested a bit, and done some tweaks.

Next up, Mopidy needs support combining multiple config files, so that the extension packages can install their own config fragments and use e.g. /var/cache/mopidy out of the box.