OctoPrint init.d $COMMAND_ARGS cli issue #1657

Closed
jdkuki opened this Issue Dec 15, 2016 · 3 comments

Projects

None yet

3 participants

@jdkuki
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" ]
then
COMMAND_ARGS="--basedir $BASEDIR $COMMAND_ARGS"
fi

if [ -z "$CONFIGFILE" ]
then
COMMAND_ARGS="--config $CONFIGFILE $COMMAND_ARGS"
fi

-z reads if $VAR null append null to COMMAND_ARGS

fixed by switching syntax:

if [[ ! -z "$BASEDIR" ]]
then
COMMAND_ARGS="--basedir $BASEDIR $COMMAND_ARGS"
fi

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 \
-- $COMMAND_ARGS serve $DAEMON_ARGS
RETVAL="$?"
fi

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 \
-- $COMMAND_ARGS serve $COMMAND_ARGS
RETVAL="$?"
fi

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

octoprint.default.txt
octoprint.init.txt

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

N/A

Link to octoprint.log

N/A

Link to contents of terminal tab or serial.log

N/A

Link to contents of Javascript console in the browser

N/A

Screenshot(s) showing the problem:

N/A

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
42e3922
@foosel foosel added this to the 1.3.1 milestone Dec 16, 2016
@foosel
Owner
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
Owner
foosel commented Jan 25, 2017

Part of 1.3.1 which has just been released.

@foosel foosel closed this Jan 25, 2017
@nkanhai
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:

DAEMON=/home/pi/OctoPrint/venv/bin/octoprint
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