Plex not stoppable

Hi,

Today I wanted to stop and restart Plex on the WebGUI in order to upgrade Plex. But the service is not stoppable anymore. So I rebooted the system and now Plex is upgraded. But this is not a solution. Is there another way to restart Plex (CLI)?

Rockons are powered by docker, so standard docker commands work fine.
As the docker instances are named, you can stop and start them by name.
The the case of Plex, the container used is named ‘plex-linuxserver.io’, so the commands would be:

docker stop plex-linuxserver.io

and

docker start plex-linuxserver.io
1 Like

Thanks @Haioken for this hint.
This works for me.

Nevertheless stopping Plex on the WebGUI is still not possible and I can’t find any log information.

Hi @upapi_rockstor,

I’m glad you could at least get what you needed done.

Before going any further, do you have any other rock-on installed and do you also observe the same thing with them, or is it specific to Plex (my guess would be it is not specific to Plex)?

Could you describe a little more what you observe in the webUI when you toggle a rock-on OFF?

  • Is the toggle button switching to the left and showing the red “OFF” text?
  • do you see the rock-on “box” darkening with the rotating white gear and the “Stopping” text or only the two rotating blue circle arrows?

I suspect the “docker stop” task triggered when toggling a rock-on off is somehow not registered when it should. I sometimes see it when the system is really busy but I always end-up being able to do so after trying again… this is why it I have not been able to track that one down so far.

Hi @Flox,

I’m afraid no. I only use Plex.

It is switching to the red “OFF” and toggles immediately back to the green “ON”
I’ve tried to make a video of this. So you can look at yourself here

only the blue circle

Thanks a lot for the additional information and for sharing this video (:+1:). It does look like the same thing I’ve noticed a few times but always ended up being working once the system settles down.

As mentioned above, we would need to find a reliable reproducer to see what is really happening but I’m afraid it’s something a lot more difficult to catch… Just in case, would you be willing to have a look at and share the following logs?

rockdev:~ # tail -f /opt/build/var/log/*ztask*

Ideally, you would run this command in a terminal, and then toggle the rock-on OFF in the webUI. If the command is registered, you should see the following:


==> /opt/build/var/log/ztask.log <==
2019-10-13 10:49:16,685 - ztaskd - INFO - Calling storageadmin.views.rockon_helpers.stop

==> /opt/build/var/log/supervisord_ztask-daemon_stderr.log <==
INFO:ztaskd:Calling storageadmin.views.rockon_helpers.stop

==> /opt/build/var/log/ztask.log <==
2019-10-13 10:49:23,297 - ztaskd - INFO - Called storageadmin.views.rockon_helpers.stop successfully

==> /opt/build/var/log/supervisord_ztask-daemon_stderr.log <==
INFO:ztaskd:Called storageadmin.views.rockon_helpers.stop successfully

Given these do not seem to be registered on your system, I suspect you will not see these entries, but it’s worth confirmation as it may reveal something helpful.

Sorry I’m not of much more help… I’m still not that familiar with our ztasks running in the background and this issue is difficult to pinpoint without having a clear reproducer.

1 Like

Hi @Flox,
thank you for your help. Here are the outputs you’ve asked for. Looks like a 500 Server Error, whatever that means.

The log was found in “/opt/rockstor/var/log”
As soon as I stopped the rock-on service I’v found a lot of these errors

2019-10-13 17:22:34,682 - ztaskd - INFO - Calling storageadmin.views.rockon_helpers.stop
2019-10-13 17:22:34,759 - ztaskd - ERROR - Error calling storageadmin.views.rockon_helpers.stop. Details:
500 Server Error: INTERNAL SERVER ERROR

function(*args, **kwargs)
File “/opt/rockstor/src/rockstor/storageadmin/views/rockon_helpers.py”, line 93, in stop
globals().get(’%s_stop’ % rockon.name.lower(), generic_stop)(rockon)
File “/opt/rockstor/src/rockstor/storageadmin/views/rockon_helpers.py”, line 110, in generic_stop
calltype=‘post’, save_error=False)
File “/opt/rockstor/src/rockstor/cli/api_wrapper.py”, line 119, in api_call
r.raise_for_status()
File “/opt/rockstor/eggs/requests-1.1.0-py2.7.egg/requests/models.py”, line 638, in raise_for_status
raise http_error
HTTPError: 500 Server Error: INTERNAL SERVER ERROR

Hope that helps for more investigation?

2 Likes

Sorry, that was my bad… My path was specific to my setup as this was on a source build. My apologies.

Thanks a lot for the information… an error 500 is actually not what I expected and I’m not sure where it could come from. I don’t recall seeing this happening in the past either so I’m a little bit unsure where to go from here. @phillxnet, would you have an idea about this one?

@Flox @upapi_rockstor Sorry can’t put much time into this currently as head down on openSUSE updating via zypper but re:

and

It is just our general server error when all else fails: ie from:

So I’d work backwards from their. Sorry I know this is just a re-description but might jog something. So in short 500 is Rockstor speak for ‘no idea’ :slight_smile:

1 Like

Hi @Flox, @phillxnet,
Today a new Plex version has been shown on the web GUI. So I tried to stop/start Plex in a terminal. Worked properly. No messages in log files.

Then I tried stop/start again on the WebGUI. Worked properly. ‘No idea’ where this 500 Error came from. Nevertheless it is gone … for now :grinning:

Output of ztask.log:

2019-10-14 15:17:07,053 - ztaskd - INFO - Calling storageadmin.views.rockon_helpers.stop
2019-10-14 15:17:11,578 - ztaskd - INFO - Called storageadmin.views.rockon_helpers.stop successfully
2019-10-14 15:17:27,748 - ztaskd - INFO - Calling storageadmin.views.rockon_helpers.start
2019-10-14 15:17:28,887 - ztaskd - INFO - Called storageadmin.views.rockon_helpers.start successfully

Thanks again for your help

1 Like

Thanks a lot for the update @upapi_rockstor, I’m really glad it seems fixed now.
I hope it’ll be a much smoother experience from now on.

Cheers,