I have to say that it is a curious one. The Rock-on service, as our other services, are automatically enabled (set to turn ON at boot) when toggled ON in the webUI. If interested, here’s where it is defined:
I’ve quickly tried to reproduce it in a VM, by turning the Rock-on service and then powering it off (not gracefully), but it then booted normally and the Rock-on service started automatically. I thus unfortunately can’t reproduce it to see whether we could do something better. Note, however, that we recently changed how we implement the docker service and particularly how we define and trigger it. These changes apply only to our soon-to-be-released Rockstor built on openSUSE, however, so that will hopefully improve its robustness and maybe help in these situations.
I believe the problem lies there, of course, as it is difficult to say whether or not (or how) this affected the docker service. What we can do, of course, is try to see how things are now. First, can you confirm that the Rock-on service repeatedly does not automatically turn ON when you reboot the machine?
If it is indeed still OFF after a reboot, please report the output of the following command to see how the docker service is (before trying to turn it back ON, of course):
systemctl status docker.service
Then, let’s see if the logs tell us something more:
journalctl -b -u docker
journalctl -b | grep docker
or, alternatively, the full log since boot (will be rather long, though, so not easy to share):
Then, turn it ON in the webUI, and confirm the service status:
systemctl status docker
Hopefully this can shed some light.
If you do not see it as enabled (for some reason), you can do so manually and see if it would now stick:
systemctl enable docker
On a side note, I would like to point you towards our implementation of the NUT protocol that allows a nice control of a UPS in case you can get your hands on one:
Hope this helps,