Mopidy with http enabled hangs at shutdown


#4

I don’t really understand that log. Why is systemd timing out after only 2 seconds? Where is it hanging?


#5

Hi,

I called systemctl stop to stop mopidy. This way, systemd sends SIGTERM and waits until this process exists. If it does not exit after a certain timeout, it sends SIGKILL to finally stop the process. The default timeout is set to 2min, I set it to 2secs for mopidy.

Marko


#6

If you put it back to the default (90 seconds on my system), you don’t see anything more in the debug log?


#7

Can you also provide the output of sudo mopidyctl deps.


#8

Nope :wink: the last three error logs are added by me in the stop_… Function. If I got the code right, nothing happens after this function anymore despite a few returns so i assume the main function is left…


#9

To mopidyctl: ok, i’m at work currently. I’ll captue the output this evening…


#10

You could try running top -H -p $(pgrep mopidy) and then watch what happens when you send SIGTERM? Chances are it’ll just be one of the unnamed threads but worth a go.


#11

Hi,

mopidyctl deps says:

Running “/usr/bin/mopidy --config /usr/share/mopidy/conf.d:/etc/mopidy/mopidy.conf deps” as user mopidy
Executable: /usr/bin/mopidy
Platform: Linux-4.14.49-v7±armv7l-with-debian-buster-sid
Python: CPython 2.7.15 from /usr/lib/python2.7
Mopidy: 2.1.0 from /usr/lib/python2.7/dist-packages
Mopidy-MPRIS: 1.4.0 from /usr/lib/python2.7/dist-packages
Mopidy-Mobile: 1.8.3 from /usr/local/lib/python2.7/dist-packages
setuptools: 39.2.0 from /usr/lib/python2.7/dist-packages
Mopidy>=0.19: 2.1.0 from /usr/lib/python2.7/dist-packages
Mopidy-TuneIn: 0.4.1 from /usr/lib/python2.7/dist-packages
GStreamer: 1.14.2.0 from /usr/lib/python2.7/dist-packages/gi
Detailed information:
Python wrapper: python-gi 3.28.3
Relevant elements:
Found:
uridecodebin
souphttpsrc
appsrc
alsasink
osssink
oss4sink
pulsesink
id3demux
id3v2mux
lamemp3enc
mpegaudioparse
mpg123audiodec
vorbisdec
vorbisenc
vorbisparse
oggdemux
oggmux
oggparse
flacdec
flacparse
shout2send
Not found:
flump3dec
mad

Marko


#12

Hi again,

with top, one can observe that three threads remain after SIGTERM.

At runtime:
555 mopidy 20 0 143648 36512 13964 S 0.0 3.8 0:03.33 mopidy
562 mopidy 20 0 143648 36512 13964 S 0.0 3.8 0:00.00 gmain
563 mopidy 20 0 143648 36512 13964 S 0.0 3.8 0:00.01 mopidy
564 mopidy 20 0 143648 36512 13964 S 0.0 3.8 0:00.05 mopidy
565 mopidy 20 0 143648 36512 13964 S 0.0 3.8 0:00.00 mopidy
566 mopidy 20 0 143648 36512 13964 S 0.0 3.8 0:00.01 mopidy
567 mopidy 20 0 143648 36512 13964 S 0.0 3.8 0:00.00 mopidy
568 mopidy 20 0 143648 36512 13964 S 0.0 3.8 0:00.00 mopidy
569 mopidy 20 0 143648 36512 13964 S 0.0 3.8 0:00.01 mopidy
571 mopidy 20 0 143648 36512 13964 S 0.0 3.8 0:00.01 mopidy

After SIGTERM:
555 mopidy 20 0 102840 36688 13964 S 0.0 3.9 0:03.37 mopidy
562 mopidy 20 0 102840 36688 13964 S 0.0 3.9 0:00.00 gmain
572 mopidy 20 0 102840 36688 13964 S 0.0 3.9 0:00.01 mopidy

Interestingly, a thread is active that is not there during normal run (TID 572).

Marko


#13

I’m experiencing this as well. Systemctl is only able to kill it after my 90 second (default) timeout. Killing it by hand with kill -9 of course works, but is a hassle.


#14

Can you confirm that disabling the http frontend also fixes it?


#15

YES! That brought it down to 9 seconds, which is workable. Thank you very much.

time systemctl stop mopidy

real 0m8.927s
user 0m0.005s
sys 0m0.005s


#16

Can you provide the full output please, @MHoyer12345678. I want to know what Tornado version you have.


#17

Which output do you need?


#18

The mopidyctl deps output.


#19

Hello,

the output I sent was the complete output I got from mopidyctl deps.

Anyway, following tornado version is installed in my system:

root@svens-radio:/home/joe# pip list | grep tornado
tornado (5.0.2)

Regards,

Marko


#20

That’s very odd.

We don’t test with Tornado v5.0 so it’s possible there’s some problems with it. Could you try downgrading to something between v4.4 and v5?


#21

Hello,

that was the right guess. I can confirm that the issue is not happening with tornado 4.4.3-1.

Cheers,

Marko


#22

I don’t suppose mopidyctl deps also now prints out the tornado version? I’m a bit puzzled by the missing stuff in your output. Or maybe it’s a Sid thing.


#23

Not looking different to me …

Running “/usr/bin/mopidy --config /usr/share/mopidy/conf.d:/etc/mopidy/mopidy.conf deps” as user mopidy
Executable: /usr/bin/mopidy
Platform: Linux-4.14.49-v7±armv7l-with-debian-buster-sid
Python: CPython 2.7.15 from /usr/lib/python2.7
Mopidy: 2.1.0 from /usr/lib/python2.7/dist-packages
Mopidy-MPRIS: 1.4.0 from /usr/lib/python2.7/dist-packages
Mopidy-Mobile: 1.8.3 from /usr/local/lib/python2.7/dist-packages
setuptools: 39.2.0 from /usr/lib/python2.7/dist-packages
Mopidy>=0.19: 2.1.0 from /usr/lib/python2.7/dist-packages
Mopidy-TuneIn: 0.4.1 from /usr/lib/python2.7/dist-packages
GStreamer: 1.14.2.0 from /usr/lib/python2.7/dist-packages/gi
Detailed information:
Python wrapper: python-gi 3.28.3
Relevant elements:
Found:
uridecodebin
souphttpsrc
appsrc
alsasink
osssink
oss4sink
pulsesink
id3demux
id3v2mux
lamemp3enc
mpegaudioparse
mpg123audiodec
vorbisdec
vorbisenc
vorbisparse
oggdemux
oggmux
oggparse
flacdec
flacparse
shout2send
Not found:
flump3dec
mad