Add systemd unit file #1716

Open
wants to merge 1 commit into
from

Projects

None yet

2 participants

@noahwilliamsson

What does this PR do and why is it necessary?

This PR adds a systemd unit file to allow OctoPrint to be started at boot time in a modern Linux distribution that runs the systemd init system. The unit file's defaults are suitable for the instructions provided in Setup on a Raspberry Pi running Raspbian

It tries to be backwards compatible with the existing init script with respect to envs defined in/etc/default/octoprint, although a few of them (OCTOPRINT_USER, DAEMON, NICE and UMASK) were not possible to support in the unit file. See the unit file for instructions on howto override these.

OctoPrint already comes with a SysV and Debian-style init script and configuration template. These work fine, even in a systemd world. But since most modern Linux distributions have moved over to systemd, I figured a systemd unit file would be a more proper way of doing things moving forward.

That way new OctoPrint users, some of who perhaps come in contact with Linux for the first time, don't unnecessarily get "exposed" to the old (and in the future, perhaps deprecated) way of adding boot services, but instead get to learn the modern way with systemctl (and journalctl for debugging) right from the start.

How was it tested? How can it be tested by the reviewer?

# Disable old OctoPrint init script
sudo service octoprint stop
sudo update-rc.d -f octoprint remove || true
sudo mv /etc/init.d/octoprint /etc/init.d/octoprint-old || true
sudo mv /etc/default/octoprint /etc/default/octoprint-old || true

# Install new OctoPrint init script
sudo cp scripts/octoprint.service /etc/systemd/system
sudo systemctl daemon-reload
sudo systemctl enable octoprint
sudo systemctl start octoprint
sudo systemctl status octoprint
sudo journalctl -u octoprint
ps auxw|grep -i octoprint

# Test change port via /etc/default/octoprint
echo PORT=1234 |sudo tee -a /etc/default/octoprint
sudo systemctl restart octoprint
ps auxw|grep -i octoprint

Any background context you want to provide?

What are the relevant tickets if any?

Screenshots (if appropriate)

Further notes

  • Debian Jessie (8.0) supports systemd
  • Raspbian Jessie was released in sept, 2015
  • The older Debian Wheezy (7.0) and Raspbian Wheezy does not support systemd

Like the author of the current init script, some helpful instructions are provided at the top of the file. They may serve as a starting point if the instructions in the wiki should be updated aswell.

scripts/octoprint.service
+# -2 ensures Octoprint has a slight priority over user processes.
+Nice=-2
+
+ExecStart=/home/pi/OctoPrint/venv/bin/octoprint serve --basedir ${BASEDIR} --config ${CONFIGFILE} --port ${PORT} --foobar $DAEMON_ARGS"
@foosel
foosel Jan 19, 2017 Owner

--foobar? O_o

@foosel
foosel Jan 19, 2017 Owner

Another thing here - I guess it's not possible to leave --config, --basedir and --port out unless the corresponding environment variables are set? The defaults in octoprint.defaults are what OctoPrint would automatically use unless overridden via command line.

@foosel
Owner
foosel commented Jan 19, 2017

Thanks! Just did a quick review and added two comments, could you take a look at those? Cheers!

@noahwilliamsson

O_o indeed. --foobar was something I used to test the failure mode. Obviously I shouldn't have committed this. Thanks for catching it, I'll update the PR.

Regarding the always present --config, --basedir and friends, I'd say this is as good as it gets if you want backwards compatibility with the existing script, and also assume most people use OctoPrint in a Raspberry Pi environment.

If you would be willing to ignore the current /etc/defaults/octoprint
I suppose you could make it slighly cleaner by using something like ExecStart=/home/pi/OctoPrint/venv/bin/octoprint serve $DAEMON_ARGS instead.

$FOO (as opposed to ${FOO}) will expand in a way that will make DAEMON_ARGS="--port 1234 --basedir /tmp/octoprint" do what you expect. (Also, note that the first argument to ExecStart= cannot be a variable).

Googling systemd variable expansion suggests it might be possible to do fancy variable expansion by involving one or more instances of bash. But by now you'd be roaming into ridiculous territory..

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