OctoPrint init.d $COMMAND_ARGS cli issue #1657

jdkuki opened this Issue Dec 15, 2016 · 3 comments


None yet

3 participants

jdkuki commented Dec 15, 2016

What were you doing?

Configured Octoprint to start / stop with init.d script provided in /scripts and set defaults in /etc/default/octoprint

What did you expect to happen?

Octoprint starts with the config file and basedir defined in /etc/default/octoprint. I am using the virtual printer plugin with a non-standard config.yaml / basedir directory.

What happened instead?

Octoprint started without the configured values set in /etc/default/octoprint for basedir or config file.

Upon further investigation of the init.d script I found two issues:

1). Script checks for empty variable to append flag to argument string.
if [ -z "$BASEDIR" ]

if [ -z "$CONFIGFILE" ]

-z reads if $VAR null append null to COMMAND_ARGS

fixed by switching syntax:

if [[ ! -z "$BASEDIR" ]]

however this requires me run the script as bash and change the first line to #!/usr/bin/bash

2). New CLI format octoprint serve ignores the --$COMAND_ARGS in init.d

When executing the init.d script, these arguments are passed in as the $COMMAND_ARGS:

if [ $RETVAL != 0 ]; then
start-stop-daemon --start --background --quiet --pidfile $PIDFILE --make-pidfile \
--exec $DAEMON --chuid $OCTOPRINT_USER --user $OCTOPRINT_USER --umask $UMASK --nicelevel=$NICELEVEL \

However, even with the changes to correctly build the string the CLI still does not input these values. It appears the arguments need to be passed in after the serve

if [ $RETVAL != 0 ]; then
start-stop-daemon --start --background --quiet --pidfile $PIDFILE --make-pidfile \
--exec $DAEMON --chuid $OCTOPRINT_USER --user $OCTOPRINT_USER --umask $UMASK --nicelevel=$NICELEVEL \

These changes allow the script to execute properly. It seems like the CLI is under some revamp. Attached my init.d below.


Branch & Commit or Version of OctoPrint

1.3.0.dev1615+g4146457 (Forked 1.3.0 tag to local server)

Printer model & used firmware incl. version

Raspian Jessie Lite Nov 25 2016 release

Browser and Version of Browser, Operating System running Browser


Link to octoprint.log


Link to contents of terminal tab or serial.log


Link to contents of Javascript console in the browser


Screenshot(s) showing the problem:


I have read the FAQ.

@foosel foosel added a commit that referenced this issue Dec 16, 2016
@foosel Don't care about common params on CLI
--basedir, --config, --verbose, --safe may now come before or after
subcommands and should still be evaluated.

For the server commands (legacy, "server" and "daemon"), the same
should now hold true for the related parameters --host, --port, --debug,
--logging, --iknowwhatimdoing and also --pid (for daemon command).

While having the parameters belong to the individual commands and only
there (which is click's basic approach) is way more cleaner, too many people
were running into issues with that strict approach after all.

I just hope the somewhat hackish approach with context injection needed to
get the less strict version to work won't backfire badly in the long run.

See also #1633 and #1657
@foosel foosel added this to the 1.3.1 milestone Dec 16, 2016
foosel commented Dec 16, 2016

Thanks. Has been fixed in e121569. I'm surprised no one stumbled over the variable checks earlier, that stuff was in there for ages.

I also made the parameter ordering matter a bit less strict in 42e3922, even though that goes basically against the principles of the underyling CLI library. I hope that won't bite me later.

In any case, fix will be in 1.3.1, to be released after my christmas break (read: early January 2017).

foosel commented Jan 25, 2017

Part of 1.3.1 which has just been released.

@foosel foosel closed this Jan 25, 2017
nkanhai commented Jan 29, 2017

This worked for me, thank you. I did a manual install and couldn't load the server after the update to 1.3.1. To fix it, I did the following:

  1. I updated the .init files that you provided here.

  2. I then did the following: Automatic start up

Adjust the paths to your octoprint binary in both ~/OctoPrint/scripts/octoprint.init and ~/OctoPrint/scripts/octoprint.default. If you set it up in a virtualenv as described above make sure your /etc/default/octoprint is modified like this:

Copy the script files to their respective folders and make the init script executable:

sudo cp ~/OctoPrint/scripts/octoprint.init /etc/init.d/octoprint
sudo chmod +x /etc/init.d/octoprint
sudo cp ~/OctoPrint/scripts/octoprint.default /etc/default/octoprint
Then add the script to autostart using sudo update-rc.d octoprint defaults.

This will also allow you to start/stop/restart the OctoPrint daemon via

sudo service octoprint {start|stop|restart}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment