No end of trouble with RockOns

absentbri · August 12, 2017, 10:41am

Unfortunately today I restarted my rockstor machine (crazy right)… Worst mistake of my life!
After the restart every single docker had no network connection, could not access anything… Plex gone, everything… gone…

Figured I would try to stop the docker services though the GUI… No luck, kept just trying to load then nothing…
Then stopped them manually with docker, they stopped.

Tried to uninstall through GUI, no luck… Removed container from docker manually… catastrophic failure, now rockstor thinks that the container still exists and cannot remove from the GUI to reinstall…

I have tried removing the rockon’s share to start over, rockstor still thinks the containers are there… I just wanted a NAS that worked, even paid for rockstor… and its useless! I have had this machine going for less than a month and its been an utter nightmare!

phillxnet · August 12, 2017, 2:53pm

@absentbri A belated Welcome to the Rockstor community.

I have just tried to reproduce this behaviour but was unable to. I have however opened a new issue with the details of my test and it’s results to address the:

and:

bits.

github.com/rockstor/rockstor-core

rock-on UI fails to reflect removed container

opened 02:01PM - 12 Aug 17 UTC

closed 05:50PM - 17 Sep 17 UTC

phillxnet

enhancement

Thanks to forum member absentbri for highlighting this issue. When a container i…s removed via command line the installed status of that container is not reflected in the UI. It is further proposed that the Web-UI uninstall procedure attempts to remove the image if it is found as well as attempting to remove the container: this leads to a cleaner re-installation of the same rock-on and some images, such as linuxserver.io's plex server (when no plex.tv account is associated), fail to fetch the latest version with the existing mechanism as the prior image is simply re-used rather than being re-downloaded/refreshed. Steps to reproduce this issue: Install HTTP to HTTPS redirect rockon ``` docker ps # to list the instance CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES dbc07c961b0d geldim/https-redirect "/bin/sh -c nginx" 7 minutes ago Up 7 minutes 0.0.0.0:80->80/tcp redirect-http-to-https ``` and it's associated image: ``` docker images REPOSITORY TAG IMAGE ID ... geldim/https-redirect latest ccf561ed3790 ... ``` Turn off rock-on in UI and we have only the image and no running container instance of that image: as expected. ``` docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES docker ps -a CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES dbc07c961b0d geldim/https-redirect "/bin/sh -c nginx" 12 minutes ago Exited (137) 2 minutes ago redirect-http-to-https ``` When the now off state Rockon is Uninstalled via the Web-UI the non running container instance is successfully removed: ``` docker ps -a CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES ``` but the image remains: ``` docker images REPOSITORY TAG IMAGE ID ... geldim/https-redirect latest ccf561ed3790 ... ``` As per current behaviour. But if we reinstall this same rock-on and then turn it off (as the default to being on); but this time we remove the now non running container instance from underneath Rockstor (ie via the command line): ``` docker ps -a CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES dcb3fb3c8475 geldim/https-redirect "/bin/sh -c nginx" 3 minutes ago Exited (137) 20 seconds ago redirect-http-to-https docker rm dcb3fb3c8475 dcb3fb3c8475 docker ps -a CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES ``` refreshing the rock-ons Web-UI does not reflect the above removal / uninstall via command line. And we have the following log report: ``` [12/Aug/2017 13:55:18] ERROR [storageadmin.views.rockon_utils:49] Error running a command. cmd = /usr/bin/docker inspect -f {{range $key, $value := .State}}{{$key}}:{{$value}},{{ end }} redirect-http-to-https. rc = 1. stdout = ['', '']. stderr = ['Error: No such object: redirect-http-to-https', ''] Traceback (most recent call last): File "/opt/rockstor-dev/src/rockstor/storageadmin/views/rockon_utils.py", line 31, in container_status '{{range $key, $value := .State}}{{$key}}:{{$value}},{{ end }}', name]) # noqa E501 File "/opt/rockstor-dev/src/rockstor/system/osi.py", line 119, in run_command raise CommandException(cmd, out, err, rc) CommandException: Error running a command. cmd = /usr/bin/docker inspect -f {{range $key, $value := .State}}{{$key}}:{{$value}},{{ end }} redirect-http-to-https. rc = 1. stdout = ['', '']. stderr = ['Error: No such object: redirect-http-to-https', ''] ``` indicating the expected rock-on container is no longer found but it's UI / db component remains. It is proposed that this is Buggy behaviour. The now non existent but still showing in Web-UI rock-on can however still be successfully removed via the Uninstall button. But as indicated earlier the image remains. ``` docker images REPOSITORY TAG IMAGE ID ... geldim/https-redirect latest ccf561ed3790 ... ``` Ready for comment on the best practice re image removal upon Uninstall. Please update the following forum thread with this issues resolution: https://forum.rockstor.com/t/no-end-of-trouble-with-rockons/3643

Software is typically developed in a few large steps followed by many many much smaller steps. The rock-ons system is currently in need of a few smaller steps (more de-bugging / refinements etc) hence my issue and it’s focus.

Thanks for helping to support Rockstor’s development via your subscription; this is appreciated. The code itself is developed in the open and released under the GPL licence.

Please see our Update Channels doc for the definition of, and intention behind, the subscription channel arrangement.

Rockstor is continuously improving (see the various dev log threads eg: Dev log for 3.9.2) but I would guess that comments such as:

are less than helpful as they lack specificity. Bugs / short comings / failures are incredibly frustrating but all those involved in Rockstor can do is try to narrow down each issue / bug exactly and then fix it. This is a slow and sometimes laborious process but one that can only be improved by attempting to work together towards a common goal.

Looking at the past responses you have received on this forum this appears to have happened.

It is likely that when the above issue receives attention other potential improvements will come to light. I’m afraid I haven’t done much work in that area of the code of late but will endeavour to chip in where I can given my current commitments elsewhere in the project.

Hope that helps and please respect that all those involved in the project are human (as far as I know) and as such they make mistakes. This is both unfortunate (the obvious lack of perfection) and fortunate, in that we are more likely to be able to communicate effectively.

Thanks for your contribution in this area.

suman · August 15, 2017, 8:57pm

Thank you @phillxnet for your detailed and thoughtful reply.

@absentbri Please send an e-mail to support@rockstor.com with your subscription order # and we’ll refund you. We definitely don’t want you to feel ripped off, though @phillxnet rightly pointed out that what we charge for is the convenient delivery of tested updates. The product is and will always be free for those willing to spend time building from source.

In general, I think many of us in the community understand and share your frustration. We are continuously iterating and we are sure to improve Rock-ons among other features.

absentbri · August 17, 2017, 12:38am

A refund is not required, my frustration reached a boiling point due to needing to once again reinstall, another restart had a kernel panic and it was just a nightmare. The OS was a total loss and I didn’t really do anything with it outside of the usage scope…

Luckily you can reinstall without loosing too much to the process (except time).