Intermittent startup issues after shutdown

What is the problem?

When restarting after system shutdown, I'm typically unable to start the server on power up. I say "typically" because occasionally I'm able to start without issue.

What did you already try to solve it?

I have tried manually stopping and starting over ssh without any success (see logs below).
Tried starting in safe mode without success.
I've tried power cycling the pi, and sometimes I'm able to startup successfully (obviously not the ideal solution).
What DOES work is activating the virtual environment: source ~/oprint/bin/activate and starting OctoPrint manually on the console: octoprint serve --debug --host Hopefully this offers some hints as to what is not configured properly.

Have you tried running in safe mode and if so did it solve the issue?

No success starting in safe mode.

Complete Logs

octoprint.log, serial.log or output on terminal tab at a minimum, browser error console if UI issue ... no logs, no support! Not log excerpts, complete logs.)

None of the logs in .octoprint/logs contain any information since the last shutdown. There is no logging from the attempted startup.

When starting manually after activating the virtual environment I do not see any errors in the debug log.

I have the following output when trying to start manually:

pi@octopi:~ $ sudo service octoprint stop
pi@octopi:~ $ sudo service octoprint start
Job for octoprint.service failed because the control process exited with error code.
See "systemctl status octoprint.service" and "journalctl -xe" for details.
pi@octopi:~ $ systemctl status octoprint.service
‚óŹ octoprint.service
   Loaded: loaded (/etc/init.d/octoprint; generated)
   Active: failed (Result: exit-code) since Sat 2020-10-17 19:33:58 EDT; 6s ago
     Docs: man:systemd-sysv-generator(8)
  Process: 678 ExecStart=/etc/init.d/octoprint start (code=exited, status=203/EXEC)

Oct 17 19:33:58 octopi systemd[1]: Starting octoprint.service...
Oct 17 19:33:58 octopi systemd[678]: octoprint.service: Failed to execute command: Exec format error
Oct 17 19:33:58 octopi systemd[678]: octoprint.service: Failed at step EXEC spawning /etc/init.d/octoprint: Exec format error
Oct 17 19:33:58 octopi systemd[1]: octoprint.service: Control process exited, code=exited, status=203/EXEC
Oct 17 19:33:58 octopi systemd[1]: octoprint.service: Failed with result 'exit-code'.
Oct 17 19:33:58 octopi systemd[1]: Failed to start octoprint.service.

Additional information about your setup

OctoPrint version, OctoPi version, printer, firmware, browser, operating system, ... as much data as possible

OctoPrint v1.4.2
OctoPi v0.17.0

Please let me know if any additional info would be helpful.
Thanks all for your help!

Hi @studley92 :

First of all : I'd advise not using the command service anymore. The command systemctl is much more indicated on recent linux systems (and by recent I mean "since the last ten years", but that's a trollish part). So, from now, systemctl start octoprint (or stop, or restart ;))

Would you mind sharing with us an extract of the result of journalctl -xe ?
(for the record : journalctl is a logging service, -x ask for the "extended information', -e jumps to the last lines of the logs).

I am probably going to be interested by the file /var/log/daemon.log . I know it's not asked usually, but since we have an error related to the service start, daemon.log is clearly indicated :slight_smile:


Off topic, but TIL. I've been using the service command, since it made more sense to me. I guess not anymore!

1 Like

Off topic also, then : I don't blame you, @Charlie_Powell . Long story made short and simple : service was a "fake command", made as an abstraction from the plain old "/etc/init.d/* [start | stop | restart]" and the RedHat chkconfig (coming from the very old init / systemV boot process, born in the 70's). Years after, we replaced systemV (controled via /etc/init.d or chkconfig) by systemd (systemctl being its main command). But we were hapilly saying people "you still can use service on every linux box, be it a RedHat or not, with the old systemV/init or the brand new systemd). As we don't have anymore to "abstract" the different ways (/etc/init.d, chkconfig, systemctl) of using services, so now you can leverage the full power of systemctl completely :wink:

Thanks @koreth.

I'll make sure to use systemctl from now on. I was relying on service based on the startup commands listed on the general "server is not currently running" screen and commands from the setup post (Setting up OctoPrint on a Raspberry Pi running Raspbian). I realize the context is a bit different.

From looking into why I used the commands I had, I decided to step through the setup post in detail, and I was able to resolve my own issue. I started from the pre-canned image, so I hadn't read the setup post in detail before. After reviewing my octoprint service and init files in comparison to, I found that somehow my octoprint.service file was not where it was supposed to be. No idea how that happened...

After following the steps in the master/scripts README to refresh my service and init files, everything is working better than it ever has!

Thanks for your help!

1 Like