Lockwood's blog

Lockwood's Blog

Auto-run PyPy Service on Pi


Today I wanted to have an example NATS client worker service written in Python utilizing my txnats and run by the PyPy interpreter on my Raspberry PI 2 auto run upon bootup.

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.

Re: upgrading the Pi from wheezy to jessie

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.


update: Jan 10:

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. I got 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 messages with make_requests.py on my laptop. After plugging it back in, both will start responding again.

update: Ensuring service on bootup.

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.

The connect-or-die pull request

Pi unplugged Pi plugged

9 Jan 2016 #microservices #IoT #Internet of Things #Raspberry Pi #Cloud