Open unitrix0 opened 1 year ago
To the best of my knowledge, this is the correct setting:
If you are running OctoPrint in a container you can only affect events in the container so you are limited to restarting the OctoPrint service (or any other process running inside the container).
Even were it shown to be possible, a process running inside a container shouldn't be instructing the host system to shutdown or reboot because that breaks containerisation. But, if your goal is to let the OctoPrint UI control the host system, I think the question to ask is why you want to run OctoPrint in a container? Why not just install it natively? Then it can do what you want.
If you simply want to do the equivalent of shutting down or rebooting the container remotely (which is what clicking on the UI buttons actually is - you're "remote" in a browser) then you can try alternatives like Portainer or SSH. Sending remote SSH commands to terminate+start or restart containers is something I do a fair bit, usually as part of a script doing something else.
I think, though, a better question might be to ask what you are trying to achieve? Why do you want OctoPrint to be able to restart either the container itself or the host system? I leave OctoPrint running all the time so I can upload GCODE files even when the printer is not switched on. Then, when I want to print something, I turn on the printer, tell OctoPrint to connect to the printer, select a file, and away it goes. I can't think of any benefit to not having it running 24x7.
After a bit more tinkering:
$ docker exec octoprint killall s6-svscan
seems to have the same effect as a reboot - the container terminates and the docker-compose restart: unless-stopped
policy kicks in. So, at a pinch, you could change the "Restart system" field to killall s6-svscan
but I don't think it does anything more than the Restart OctoPrint
. In particular, it doesn't look like a killall has the effect of terminating and recreating the container (in the docker sense) so, if there is any "mess" left around as a side effect of the killall, you're not getting a clean slate, in the same way you would if OctoPrint was a native install and you rebooted the host.
Your absolutely right. I was using a Pi3 until now for octoprint and when I didn't need the printer I shut everything down. But of crouse this doesn't make sense with a docker container. I went for it because of the easier installation but it seems I have to do the work 😏
Discussed in https://github.com/OctoPrint/octoprint-docker/discussions/255