One way to do this is with systemd, which is built into Rasbian jessie. You define a service file that defines the application launch command to run and things like its working directory. How To Autorun A Python Script On Boot Using systemd was a helpful reference.
With a fresh install of Raspbian jessie, I downloaded pypy and got pip installed. My other Raspberry Pi 2 had Rasbian wheezy on it, so began the upgrade.
Because txnats depends on Twisted, I initially followed Deploying Twisted with systemd, ran into trouble where the service failed to start. Wrong permissions, which the documention doesn’t really talk about, were the problem. The service file they show has the User as nobody and that was not working. I ended up commenting out the User and Group directive, which is probably the wrong thing to do, but it allowed the thing to run. Will look into fixing this later.
To go from the example web service to my distributed responder
service, I moved the pypy directory to
/usr/local/, changed the permissions and
linked the pypy binary to
~/bin/ so I could run pypy without typing
the full path.
I built a Makefile with the steps I took, so I could easily repeat them and build upon this example with less tedium. I hate tedium.
txnats example distributed responder service with instructions.
This process is somewhat interactive. It stops to ask questions, such as use the old settings or the new settings… I had begun the upgrade in a tmux session, so I could disconnect without interupting the process. I had been checking in with the progress every once and a while this evening and answered it’s queries, but just now, I found the tmux client had been upgraded and was no longer compatible with the tmux server running my session. The first solution on SO was to kill all the sessions and start over. Killing a session blindly in the middle of an hours long upgrade was not something I wanted. As SO would have it, more intelligent answers don’t always get the vote, but they’re there if you look. attach Back in business. Next time I may just re-image the thing.
Reboot the upgraded Pi so
systemd and other things are properly launched.
I ran into this issue when trying out the instructions from above upon this Pi.
Failed to get D-Bus connection: Unknown error -1
when I ran
make add-services. After a reboot, I tried that last step again
and it worked. I also found a not needed step caused a problem and changed
the README to deal with it.
Now I can unplug one of the two Pis and still have services respond when publishing
on my laptop. After plugging it back in, both will start responding again.
In testing, I found it better to make the service exit immediatly upon failing to connect to a NATS server so the process manager can do it’s job and try restarting again. The system may not have the network completely connected by the time systemd starts the service, and this lets it try again later. After this, I could reliably power up the pi and have it responding quickly.