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)?
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
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?
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 (). 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.
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?
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’
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
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
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,