Raspberry Pi Cluster Node – 12 Automatic Start with rc.local

This post builds on my previous posts in the Raspberry Pi Cluster series by creating a script which automatically starts the slave and master with rc.local.

What is the rc.local file?

The rc.local file is used on many Linux operating systems to schedule operations to run after services are started on the machine.

On all supported operating systems the rc.local file will be run as the root user. This means that all commands in the file will be run as the root user.

Typically as stated above this will be run once other services on the machine are started. However this is open to the operating system implementation. You may need to check your operating system for specifics.

The Raspberry Pi default Raspbian distribution will run this once the standard system services are started.

Making our python scripts runnable from the shell

Currently we have been running our python scripts by running python <scriptname>. This works well but to run it easier we want to launch it without running stating what python to run.

First to be able to launch the script immediately from the command line is to make it executable. This can be done on Linux with the following command line:

chmod u+x <script name>

Once this is done you are able to launch the script by running ./<script name>.

However this will only work if the shell can detect what executable it should run it with. A hint can be given to the shell by using a shebang.

This is a hint in the first line of a script to tell it which executable to run. For python files you can place the following in the top line of the file.

#!/usr/bin/env python

This tells the shell to run this file with the script /usr/bin/env python. This finds the location of python by searching the environment variables.

With these two changes we will be able to launch both slave and master using the following commands.

./basic_slave.py
./basic_master.py

To run these scripts from the startup rc.local script we will want to change some relative references.

Changing relative file references

Currently the scripts assume that all files are located in the current working directory. When the scripts are launched under rc.local this will not be the case.

One way to resolve this is to change the current working directory, to the location of the scripts before running. However a more versatile method is to load files relative to the scripts.

To do this I am going to be referencing the directory of the scripts using the following code.

os.path.dirname(os.path.realpath(__file__))

This gets the directory that the current file is located within. Using this and os.path.join() I can reference the configuration files relative to the script directory.

This then changes our config loading line, to the following:

config.read(os.path.join(os.path.dirname(os.path.realpath(__file__)), 'rpicluster.cfg'))

In addition to this, we want to make sure the log files are written to the correct directory. So the code to save the log files is changed too.

fileHandler = logging.FileHandler(os.path.abspath(os.path.join(os.path.dirname(os.path.realpath(__file__)), "..", filename)))

In this case, we reference the directory above the one that the file lives in. To do this .. is used to reference the directory above, and os.path.abspath() is used to simplify the path.

Adding our scripts to rc.local

Now the scripts have been changed to properly be ran from rc.local we can add the entry. To edit the rc.local I am going to use nano with the following command.

sudo nano /etc/rc.local

If you are unsure how to use nano, I suggest you read my full blog post on using nano.

/home/chewett/pg/RaspberryPiCluster/12_automatic_start_rclocal/basic_master.py 2&>1 > /dev/null &

Here we launch the basic_master.py file on startup. We redirect all standard output and error to /dev/null to surpress any output. Finally & is added to the end of the line to launch it in the background.

Summary

Now we have our slaves running their scripts when they are booted up. This allows them to automatically join the cluster without further intervention.

The full code is available on Github, any comments or questions can be raised there as issues or posted below.