Restart server command stops but doesn't restart server

Get Help
1

What is the problem?

In the OctoPrint server settings, I am setting the Restart Sever command to "~/octoprint/venv/bin/octoprint daemon restart"
It stops the server but fails to restart it.

What did you already try to solve it?

I know the command is recognized (and in particular the path is correct) because it succeeds in stopping the server.
The daemon restart also works fine when I ssh into my RPI and run it from the shell command line.

Just don't understand why it doesn't do the start part...

I have tried this on an RPI3 and an RPI4 -- everything else works fine...

2

why not use what's default in octopi image sudo service octoprint restart? This assumes you've either used the octopi image or followed the manual install instructions for adding the service.

3

Because I manually installed on my own existing PI installation and I didn't want to install Octoprint as a service (so no need for sudo/superuser privileges).

It's strange that the command only half works in that it shuts down but doesn't restart.
Yet, it works from the command line so shouldn't be a permission issue...

Here is the relevant portion of the octoprint log file when I trigger shutdown from the Octoprint web interface:

2022-04-28 22:06:25,172 - octoprint.server.api.system - INFO - Performing command for core:restart: ~/octoprint/venv/bin/octoprint daemon restart
2022-04-28 22:06:26,040 - octoprint.server - INFO - Shutting down...
2022-04-28 22:06:26,646 - octoprint.server - INFO - Calling on_shutdown on plugins
2022-04-28 22:06:26,647 - octoprint.events - INFO - Processing shutdown event, this will be our last event
2022-04-28 22:06:26,649 - octoprint.events - INFO - Event loop shut down
2022-04-28 22:06:26,663 - octoprint.plugins.HeaterTimeout - INFO - Shutting down...
2022-04-28 22:06:26,665 - octoprint.server - INFO - Cleaning up daemon pidfile
2022-04-28 22:06:26,665 - octoprint.server - INFO - Goodbye!

So you can see that the command is sent and processed but only the shutdown occurs...

In contrast, when I issue the command from the CLI I get:

2022-04-28 22:07:54,771 - octoprint.server - INFO - Shutting down...
2022-04-28 22:07:54,826 - octoprint.server - INFO - Calling on_shutdown on plugins
2022-04-28 22:07:54,827 - octoprint.events - INFO - Processing shutdown event, this will be our last event
2022-04-28 22:07:54,828 - octoprint.events - INFO - Event loop shut down
2022-04-28 22:07:54,842 - octoprint.plugins.HeaterTimeout - INFO - Shutting down...
2022-04-28 22:07:54,843 - octoprint.server - INFO - Cleaning up daemon pidfile
2022-04-28 22:07:54,844 - octoprint.server - INFO - Goodbye!
2022-04-28 22:07:55,233 - octoprint.startup - INFO - ******************************************************************************
2022-04-28 22:07:55,235 - octoprint.startup - INFO - Starting OctoPrint 1.7.3
2022-04-28 22:07:55,236 - octoprint.startup - INFO - ******************************************************************************
2022-04-28 22:07:55,543 - octoprint.util.connectivity.connectivity_checker - INFO - Connectivity changed from offline to online
2022-04-28 22:07:55,576 - octoprint.util.connectivity.connectivity_checker - INFO - Connectivity state is currently: online
2022-04-28 22:07:55,577 - octoprint.util.connectivity.connectivity_checker - INFO - Connecting to 1.1.1.1:53 is working
2022-04-28 22:07:55,577 - octoprint.util.connectivity.connectivity_checker - INFO - Resolving octoprint.org is working
etc.

So that the restart follows the shutdown...

4

not installing it as a service is the difference. As a service, systemctl is the actor, it stops the service, waits a little and starts a new instance.
In your setup there's only the octoprint instance. It 'knows' that the 1. part of restart is to stop, so it stops. And then nothing is left to trigger a new start.

5

The difference is here that they are using the built in command octoprint daemon stop|start|restart and the restart is not working. It should work, but I suspect this is not a widely used function so who knows if it is or isn't.

6

wonder if you could use the old trick of ~/octoprint/venv/bin/octoprint daemon stop && ~/octoprint/venv/bin/octoprint daemon start instead?

7

wonder if you could use the old trick of ~/octoprint/venv/bin/octoprint daemon stop && ~/octoprint/venv/bin/octoprint daemon start instead?

I tried that... it didn't work... I don't think it allows shell constructs

8

The difference is here that they are using the built in command octoprint daemon stop|start|restart and the restart is not working. It should work, but I suspect this is not a widely used function so who knows if it is or isn't.

I will try embedding it in a shell script -- as I suspect that perhaps Octoprint is identifying it as a native command and substituting it's own potentially buggy version.

9

The difference is here that they are using the built in command octoprint daemon stop|start|restart and the restart is not working. It should work, but I suspect this is not a widely used function so who knows if it is or isn't.

Not sure I understand. It seems like I can put any command there. E.g., I tested using 'touch <random file' and it worked. To that extent, "octoprint daemon restart" is just a *nix command and should be executed as such.

Whether I am using a system-wide service or a command line daemon shouldn't make a difference if octoprint is just forking the command and executing it. Unless Octoprint is identifying "octoprint daemon" as special and treating it "specially"

10

The command octoprint daemon is functionality that is provided by OctoPrint, rather than something like systemd which is separate on the OS side. Since 99%+ people use a service of some kind I have no idea if it works, maybe the implementation is not working right because no one has tested it works recently.

Maybe it's never been used as the server restart command? Who knows. My guess is that 'stopping' the server will also include stopping running the restart command, so the start but never gets executed. Whereas when you run it in the terminal through SSH it would be a separate process.

11

I think I solved it!

If I put the command in a shell script, it fails too.
But if I pipe stdout onto a file (or even /dev/null) then it works.
If I only pipe stderr, then I get the error message:

Exception ignored in: <_io.TextIOWrapper name='' mode='w' encoding='UTF-8'>
BrokenPipeError: [Errno 32] Broken pipe
Exception ignored in: <_io.TextIOWrapper name='' mode='w' encoding='UTF-8'>
BrokenPipeError: [Errno 32] Broken pipe

(1 error message for the 'stop' part and 1 error message for the 'start' part)

This seemingly confirms that starting and/or stopping the daemon requires the ability to write to stdout. However, 'stopping' seems to still stop the daemon (despite the error message) while 'starting' fails to start the daemon.

So, in conclusion, the following works:

~/octoprint/venv/bin/octoprint daemon restart > /dev/null

2 Likes
12

Thanks for sharing. I think you are the first person that I've ever encountered that doesn't run OctoPrint as a service in linux. Just curious, how are you starting it on boot?

13

I just started "playing" with OctoPrint yesterday on one of my existing PIs.

  • I use a common setup on all my PIs, so I didn't want to play around with a new Raspberry OctoPrint distro and have to set it all up from my scratch to my liking and customization.
  • Also, at least to start and maybe even for the long term, I like that it runs from user space and I can keep the entire relevant python libraries & executables all within my user directory -- which again makes it easy to maintain across other PIs that don't need the OctoPrint functionality -- so I didn't want to install it as a system service.
  • Finally, most such system services are just wrappers around relevant daemon scripts anyway.

So, to answer your question directly, I either can launch it manually or add it to my user crontab with a line like:

@reboot ~/octoprint/venv/bin/octoprint daemon start

Since cron consumes the stdout, there is no need to pipe to /dev/null.

1 Like
14

@puterboy - I think you solved the problem I was having with service octoprint restart on freebsd (jail in Truenas.) I added the > /dev/null and it now works!

Thank you!

15

@jneilliii - Would be great if code could be fixed to not require existence of an attached or piped stdout.
Should require only a trivial code change... at a minimum pipe to /dev/null if no stdout specified or attached.

16

I'm not sure if there are reasons for doing it the way it's being done now, @foosel would have to comment on that. The fact that you can add your own pipe to /dev/null in the setting itself it might make more sense to just document that for people that are experiencing this issue.

17

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.