Extension development // Confusion with Mopidy as a service

General
1

Hello there,

Sorry in advance for a long post, but I’ve been banging my head against the wall for a good while now, and I’m feeling rather confused.

I’ve been experimenting with Mopidy extension development in the past months, encouraged by the very approachable documentation which made getting started relatively painless. I’ve been mainly experimenting with the Mopidy-Beets extension, since I’m a big fan of beets, and found the Mopidy extension of it a bit lacking.

After getting my initial ideas realized, I wanted to try if I could get the album artwork visible according to the new paradigm. While I was able to get a method going using a virtual environment on my laptop, I’m having a hard time getting anywhere on my “production environment” using Mopidy as a service, even though my earlier fixes translated fine.

In a nutshell, it seems like that if I invoke Mopidy from CLI using sudo -u mopidy /usr/bin/mopidy --config /etc/mopidy/mopidy.conf, my new method gets invoked expectedly, while when running Mopidy as a service the method does not get invoked under the same operating conditions, even though sudo service mopidy status lists a very similar sounding command:

CGroup: /system.slice/mopidy.service
└─2543 /usr/bin/python3 /usr/bin/mopidy --config /usr/share/mopidy/conf.d:/etc/mopidy/mopidy.conf

I’m very puzzled at this point and have been trying many different things to solve the issue. I installed my modified extension via sudo python3 -m pip install ., and the modified source code is visible in /usr/local/lib/python3.7/dist-packages/mopidy_beets. At some point I was thinking whether it’s a thing with apt vs pip installed Mopidy, but both /usr/bin/mopidy and /usr/local/bin/mopidy invoke the method when running from the CLI, and swapping /usr/bin/mopidy to /usr/local/bin/mopidy in the service file does not change anything. At this point I don’t know whether the problem is in Mopidy as a service using somehow different source code compared to the CLI version resulting in the method not getting invoked, or the modified extension appearing somehow non-modified in the service’d case. It’s weird, because my earlier fixes ran fine even when using service’d Mopidy, and I don’t see why this fix would be any different.

Here’s also partial output from sudo mopidyctl deps:

Running "/usr/bin/mopidy --config /usr/share/mopidy/conf.d:/etc/mopidy/mopidy.conf deps" as user mopidy
Executable: /usr/bin/mopidy
Platform: Linux-5.10.103-v7+-armv7l-with-debian-10.13
Python: CPython 3.7.3 from /usr/lib/python3.7
Mopidy: 3.3.0 from /usr/lib/python3/dist-packages
Mopidy-Beets: 4.0.1 from /usr/local/lib/python3.7/dist-packages
  requests: 2.22.0 from /usr/local/lib/python3.7/dist-packages
    idna: 2.6 from /usr/lib/python3/dist-packages
    chardet: 3.0.4 from /usr/lib/python3/dist-packages
    certifi: 2018.8.24 from /usr/lib/python3/dist-packages
    urllib3: 1.24.1 from /usr/lib/python3/dist-packages
  setuptools: 40.8.0 from /usr/lib/python3/dist-packages
  Pykka: 2.0.3 from /usr/lib/python3/dist-packages
  Mopidy: 3.3.0 from /usr/lib/python3/dist-packages

Looking forward to any fresh insights!

2

Allright, this problem sort of solved itself, as apt.mopidy.com was pushed to 3.4.1, making the serviced version use the appropriate new methods without problems. I think the original issue is in the “serviced” version being somehow tied to the instance of mopidy installed by apt (/usr/bin/mopidy), and switching it to use the upstream python version (/usr/local/bin/mopidy) not being as trivial as fiddling the service file a bit.

So all good!

3

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.