I kind of made some catastrophic mistakes in a very unfortunate order
( rm -rf /mnt2/docker for instance) and after that I do not see the rockon I want to install (Duplicati) in the repository.
Is there I can completely reset the rockon service and start all over again?
The only thing I have not tryed is to drop the whole ~/docker share
I believe that by
/mnt2/docker you refer to the rock-ons root folder, is that correct?
If that is indeed the case, then I believe you are correct and need to reset the rock-on service:
- If it is not already OFF, turn the Rock-ons service OFF from Rockstor’s webUI under System > Services
- Delete the share you used as rock-ons root from Rockstor’s webUI if still present.
- Recreate a share to be used as rock-ons root.
- Configure the Rock-ons service to use this share from Rockstor’s webUI under System > Services (http://rockstor.com/docs/docker-based-rock-ons/overview.html#the-rock-ons-root).
- Toggle the Rock-ons service back ON.
- You should now be able to successfully click the Update button on the Rock-ons page and install your rock-on of choice.
Hope this helps,
Tahnk you, this did the trick.
Is there a way I could perform this action (stopping the rock-on service) via the CLI?
I managed to dig myself in a hole so once I shitch off the Rock-On service via the GUI the whole server starts failing (no GUI, many of the core processess enter Deadlock states and systemctl stops responding) and the only solution is a hard reset.
My immediate thought is to try:
systemctl stop docker
You do mention, however, that
systemctl stops responding so it may not help in your case. I’m a little surprised by the fact that you’re experiencing issues when turning the rock-on service OFF, though (as opposed to ON). Would you have more details about that? Do you see anything in the logs? Can you turn it on without problem? As always, it’s always informative to know what version of Rockstor you are using in case an update is available.
Thanks for letting us know. There are more direct options to stop the docker service more “manually” but it’s always better to keep those only if the rest doesn’t work.
So, I am using RockStor 3.9.2-50
After a hard reboot I went to GUI and turned OFF the Rock-on service.
After bout two minuted I received:
##### Houston, we’ve had a problem.
Unknown internal error doing a POST to /api/sm/services/docker/stop
systemctl status docker -l
[root@vault ~]# systemctl status docker -l
● docker.service - Docker Application Container Engine
Loaded: loaded (/etc/systemd/system/docker.service; enabled; vendor preset: disabled)
Active: deactivating (final-sigkill) (Result: timeout) since Tue 2019-12-10 21:12:17 CET; 2min 14s ago
Process: 5037 ExecStart=/opt/rockstor/bin/docker-wrapper /mnt2/docker (code=killed, signal=TERM)
Main PID: 5037 (code=killed, signal=TERM)
└─5120 /usr/bin/dockerd --log-driver=journald --storage-driver btrfs --storage-opt btrfs.min_space=1G --data-root /mnt2/docker
debug2: channel 0: window 999277 sent adjust 49299
Dec 10 21:11:55 vault systemd: Started Docker Application Container Engine.
Dec 10 21:12:17 vault systemd: Stopping Docker Application Container Engine…
Dec 10 21:13:47 vault systemd: docker.service stop-final-sigterm timed out. Killing.
Also the GUI ater that is throwing at me Gateway time-out error as if nginx is not able to process my request.
I there another log I could take look at?
Thanks for the additional input.
It seems that, overall, something is taxing your resources and causing all sorts of processes to time-out. As you can see below:
The docker service was not terminating as it should have been as it timed-out while doing so. It thus seems that, as a result, you still have the docker daemon running:
To finish stopping it, you could first verify its PID using
ps or even just
top. Here’s a rough way to do so below:
ps aux | grep -v grep | grep docker
If you still see a line for the
docker-containerd, you can kill those two processes (
If you indeed have a docker container running that is using all your resources, then it will help, but it all depends on why this happens to begin with (if that is the case, indeed).
/opt/rockstor/var/log/rockstor.log is always a good resource. You will also find more specific logs in this folder in case you’re curious.
Overall, I would try to figure out what is using all your resources (again, if that is indeed the case) and then we should have a better idea of the root cause of your problems.