Just leaving some thoughts here for posterity... @toofewacres to be clear I'm not asking you to respond (unless you want to 😄)

As @ax42 mentioned It's designed to just have a container restarted by the host as the best way, especially if you're doing something that changes the container environment, as a restart is the only way to load updates to the container environment.

The command posted works to restart all services (not just octoprint), but may not have the same effect that restarting octoprint would on a normal operating system (for example after plugin update or intallation), and I'm afraid that could cause problems for users who aren't aware of this.

Almost thinking we need a section in the docs for octoprint-docker about "known differences/issues using octoprint in a container".

That being said, it would be worth investigating ways to trigger a container reload from within the container... although that comes with it's own challenges for container permissions/docker-in-docker types of scenarios.

One possible way would be if the hosts daemon was configured for the api to be acccessible on a port (by default it binds to a fd), and the container could send an http request from within the container to the api to trigger restart of the container.

The other approach is to just create a finish script for the octoprint service that causes the container to shut down, then a command to kill the octoprint service would be the server restart command you would configure... and as long as you're using a restart option in docker/compose, the container should automatically spin back up.

That last one is the approach I'm going to start with and will go from there.

Add Docs for restart server command from within the App #90

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions