Brewpi process as service

Lukas_Demetz · September 23, 2015, 5:54pm

Hi guys,

I don’t know if it’s just a problem with my install, however I never had the brewpi script running on my Raspberry, so I had to start it by hand and leave it running in an SSH terminal. Should be easier, so I found the following solution, which is pretty straightforward:

Open an SSH connection to your Raspberry

Execute this command:

sudo apt-get install supervisor

Create a file at /etc/supervisor/conf.d/brewpi.conf by using

sudo nano /etc/supervisor/conf.d/brewpi.conf

And insert this content:

[program:brewpi]
directory=/home/brewpi
environment=ENV_VARIABLE=example,OTHER_ENV_VARIABLE=example2
command=python /home/brewpi/brewpi.py
autostart=true
autorestart=true

Save with STRG+X and confirm with Y.

Reload supervisorctl with this command:

sudo supervisorctl update

And then, you can start brewpi using:

sudo supervisorctl restart brewpi

You will find that it will start itself at startup, and all commands are still working as usual (except --kill, as supervisorctl will restart the process as soon as it gets stopped by whatever reason).

Hope this helps

Lukas

Elco · September 23, 2015, 11:15pm

Hi Lukas,

This is pretty sweet.
Perhaps this can replace our cron job in /etc/cron.d/brewpi

It is managed by this update script:

github.com

BrewPi/brewpi-script/blob/master/utils/updateCron.sh

#!/bin/bash
# This bash script will update the CRON job that is used to start/restart/check BrewPi

############
### Functions to catch/display errors during setup
############
warn() {
  local fmt="$1"
  command shift 2>/dev/null
  echo -e "$fmt\n" "${@}"
  echo -e "\n*** ERROR ERROR ERROR ERROR ERROR ***\n----------------------------------\nSee above lines for error message\nScript NOT completed\n"
}

die () {
  local st="$?"
  warn "$@"
  exit "$st"
}

# the script path will one dir above the location of this bash file

This file has been truncated. show original

Lukas_Demetz · September 24, 2015, 5:32am

Hi Elco,

well, actually we would not even need an entry in the crontab for the brewpi.py process. We could simply do the few settings during install and that’s it. In that case, we’d have to remove the entry in crontab in case there are any, and maybe check if supervisorctl is installed… What do you think?

Also, it would make sense to do a few changes to the brewpi.py script, so that start and stop would use supervisorctl. It would even be cleaner to use Python’s daemon library to make a daemon, but I guess we could do that when we rewrite the file

Elco · September 24, 2015, 9:33pm

I don’t really like the current implementation where cron checks whether the script should be running every minute. It sucks that it can take up to a minute for the script to start after clicking the button in the web interface. I just didn’t want the web UI to be able to start processes, which would be a security issue. So the web interface removes/creates a file to indicate that the script should be running and the cron job checks the file.
Something like supervisord will be much cleaner. @vanosg, what do you think about this?

vanosg · September 29, 2015, 3:32am

We’ve talked about several implementations like this over the past two years - https://github.com/BrewPi/brewpi-script/issues/16 is the one I can quickly find, and I know mdma had some thoughts on it at one point too. I absolutely agree that cron, while easy, lacks the graularity that other services provide, and you can get rid of the DONOTRUN file, too . supervisor, systemd, daemontools all provide similar functionality. someone just needs to take a whole-system approach to designing a software roadmap, set the future milestones, and let people develop towards it. In this specific case, there are lots of options and any one is mostly as good as another.

Perhaps the one benefit that systemd has over anything else is that it now comes included by default on raspbian (it is the init process that controls everything)- it is one less thing you will need to manually install (some would accuse the project of bloat), and will be supported in all future versions to come, for quite some time. (Note: the Jessie version of Debian [the current stable version] uses systemd by default, but I the raspbian image from raspberrypi.org is still running from Wheezy [the previous stable version] which has not transitioned yet. You can change to run systemd on Wheezy rather easily, and then when the Jessie version comes out, you’re already good to go).

In conclusion- all good solutions, one is just about as good as the next, but I’d go with systemd since it is part of the base distribution now.