nightmicu
Posts: 4
Joined: Tue Apr 02, 2013 8:23 pm

Problems running a Python program on startup

Tue Apr 02, 2013 8:35 pm

Greetings,

Brand new Pi user and somewhat noob Python user as well. I have a Python program that I am trying to run when the Raspberry Pi boots up. I have spent the past two or so hours searching Google for a working solution and just cannot seem to get it to work. Here is what I have figured out so far -

The program I am trying to run is located at /home/pi/TwoTone/TwoToneDetect59Pi.pyc and I have been starting it with 2>/dev/null because of lots of ALSA errors that come up.
I wrote a bash file, located at /home/pi/twotone.sh with the following contents - the change directory was required to make the program run (couldn't find a file without it).

Code: Select all

#!/bin/bash
cd /home/pi/TwoTone
python TwoToneDetect59Pi.pyc 2>/dev/null
I followed a tutorial for starting an application at boot by placing a script in /etc/init.d. Here is what I ended up with:

Code: Select all

#! /bin/sh
# /etc/init.d/TwoTone

### BEGIN INIT INFO
# Provides:          TwoTone
# Required-Start:    $remote_fs $syslog
# Required-Stop:     $remote_fs $syslog
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: Simple script to start a program at boot
# Description:       A simple script from www.stuffaboutcode.com which will start / stop a program a boot / shutdown.
### END INIT INFO

# If you want a command to always run, put it here

# Carry out specific functions when asked to by the system
case "$1" in
  start)
    echo "Starting TwoTone"
    # run application you want to start
    sh /home/pi/twotone.sh
    ;;
  stop)
    echo "Stopping TwoTone"
    # kill application you want to stop
    killall  TwoTone
    ;;
  *)
    echo "Usage: /etc/init.d/TwoTone {start|stop}"
    exit 1
    ;;
esac

exit 0
It works fine when I type sudo /etc/init.d/TwoTone start (or stop), I set the permission as instructed in the tutorial, and added it to startup. As the Pi boots, I see it last in the line - "Starting TwoTone" - but after everything has finished loading (X starts), it does not appear to be loaded.

What am I missing here? Basically, I need to do what twotone.sh does when the Raspberry Pi boots.

Thanks!

Schorschi
Posts: 220
Joined: Thu Nov 22, 2012 9:38 pm

Re: Problems running a Python program on startup

Wed Apr 03, 2013 1:13 am

Which Linux distribution are you using?

nightmicu
Posts: 4
Joined: Tue Apr 02, 2013 8:23 pm

Re: Problems running a Python program on startup

Wed Apr 03, 2013 1:16 am

Raspbian wheezy

Schorschi
Posts: 220
Joined: Thu Nov 22, 2012 9:38 pm

Re: Problems running a Python program on startup

Wed Apr 03, 2013 1:48 am

Did you do? Some Linux distributions have moved on to using systemctl versus older chkconfig... if using chkconfig... make sure the right runlevels are enabled... chkconfig on... defaults to 2345...

To setup...
# chkconfig --add <service/script name>
# chkconfig on <service/script name>
# chkconfig --list <service/script name>

To test...
# service start <service/script name>

To setup...
# systemctl enable <service/script name>.service

To test...
# systemctl start <service/script name>.service

Schorschi
Posts: 220
Joined: Thu Nov 22, 2012 9:38 pm

Re: Problems running a Python program on startup

Wed Apr 03, 2013 1:54 am

My date time is off on the Pi I tested on... but the configuration worked... in my /var/log/messages... The script name is 'automatic'... After reboot...

Oct 31 19:06:18 Prototype logger: /etc/rc.d/init.d/automatic Start

My test script 'automatic' just drops some text into the messages log, via the logger command.

nightmicu
Posts: 4
Joined: Tue Apr 02, 2013 8:23 pm

Re: Problems running a Python program on startup

Wed Apr 03, 2013 12:25 pm

Sorry, I've never dealt with anything like this before. Are those commands that I need to place in the TwoTone file under /etc/init.d? Do those replace what is already there?

An example with the commands in my post would be very helpful. I may elect to handle this with VNC but I'd like both, if possible.

Thanks

SSilver2k2
Posts: 179
Joined: Wed Jun 06, 2012 1:51 am
Location: United States
Contact: Website AOL

Re: Problems running a Python program on startup

Wed Apr 03, 2013 8:17 pm

So, this is what I did with PIP, which runs at bootup.

the full installer code is here: https://github.com/ssilverm/PiMAME/blob ... install.py though it is not very clear to read.

basically, you make a file that looks like this:

#!/bin/bash
### BEGIN INIT INFO
# Provides: name
# Required-Start: $remote_fs $syslog
# Required-Stop: $remote_fs $syslog
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: Example initscript
# Description: This file should be used to construct scripts to be
# placed in /etc/init.d.
### END INIT INFO
your commands here
echo "hi"

that should be saved in /etc/init.d/yourshellscriptname.sh
then sudo chmod +x /etc/init.d/yourshellscriptname.sh
sudo update-rc.d yourshellscriptname.sh defaults

And then to test it just do sudo /etc/init.d/yourshellscriptname.sh

The next time you boot up your script shoudl run.
My blog of various geeky things - http://blog.sheasilverman.com
PiPLAY - http://piplay.org
DeskCade.com - Mini Raspberry Pi Arcade Cabinet

Schorschi
Posts: 220
Joined: Thu Nov 22, 2012 9:38 pm

Re: Problems running a Python program on startup

Fri Apr 05, 2013 3:27 am

Once you have your script in 'init.d' the only thing you need to do is tell Linux to see it as a service, or in your case a script, rather than a full service, since the script is only 'started' never stopped like a true service.

For example, again I am using Fedora, but other Linux distributions will be similar...

# ls /etc/init.d
functions netconsole network


There are two services... netconsole and network.

How you tell Linux to recognize the script as a startup script depends to some degree what variant of Linux you use. Almost any version of Linux that uses init.d oriented services, should honor the chkconfig commands I used, but newer distributions have started to use a different architecture for services, that is based on SysV or systemctl methodology, but for now, ignore that. Using rc-update is a bit cleaner way to do it, but gets you to the same result as my direct chkconfig commands, if your distribution of Linux supports it.

# chkconfig --list
netconsole 0:off 1:off 2:off 3:off 4:off 5:off 6:off
network 0:off 1:off 2:on 3:on 4:on 5:on 6:off


In your script you should/need to have the right header so that the service engine knows what to do with your script (depending on the method you use to enable your script). In your case, that appears to be correct. However, understanding what INIT INFO means is key. If you look in the init.d directory or the rc* directories (/etc/init.d and /etc/rc*) you will see how Linux sets up priority among the various services and scripts and how Linux uses run levels to set the scope of when a script or service is run.

Traditional Linux has 6 run levels... 1 and 6 your can ignore other than think of 1 as power up and 6 as power down for now, oh, 1 and 6 are always run, and rarely would you need to know more than that about run levels 1 and 6. Run levels 2, 3, 4, 5 have specific meaning and are exclusive of each other, if you run 3 you don't run 5... for example run level 3 is multiuser console, whereas run level 5 is multiuser graphical/GUI... so if I had a script or service I only want to run when I am in console mode... I would set it to run at run level 3. If I had a service or script I wanted to only run when GUI is to be used, I would set it to run at run level 5. As an example... looking at the network script...

#! /bin/bash
#
# network Bring up/down networking
#
# chkconfig: - 10 90
# description: Activates/Deactivates all network interfaces configured to \
# start at boot time.
#
### BEGIN INIT INFO
# Provides: $network
# Should-Start: iptables ip6tables
# Short-Description: Bring up/down networking
# Description: Bring up/down networking
### END INIT INFO


Notice the 10 and 90 chkconfig values in the INIT INFO header, this will be significant as you read more below. And notice the network script does not explicitly define run levels? It should but it doesn't... someone was a bit sloppy in their INIT INFO header definition sometime in the past... I will explain why this is of interest below as well...

If you look in the rcX.d directories, where X is the run level, you can see what is run at what level. So chkconfig <service> on, by default enables <service> to run at levels 2, 3, 4, 5. The actual script for the service is in init.d, but links to that script are defined in the given rcX.d directories. The INIT INFO can outline this as well if explicit run levels are itemized in the INIT INFO hearder, telling chkconfig what to do when you 'add' your script to init.d via chkconfig or rc-update commands should match the INIT INFO header, again as I referenced in my previous post, but I digress a bit, so looking at the /etc/rc.d directory, you can see all the run levels defined...

# ls /etc/rc.d
total 32
drwxr-xr-x 2 root root 4096 Mar 9 00:55 init.d
drwxr-xr-x 2 root root 4096 Mar 9 00:55 rc0.d
drwxr-xr-x 2 root root 4096 Mar 9 00:55 rc1.d
drwxr-xr-x 2 root root 4096 Mar 9 00:55 rc2.d
drwxr-xr-x 2 root root 4096 Mar 9 00:55 rc3.d
drwxr-xr-x 2 root root 4096 Mar 9 00:55 rc4.d
drwxr-xr-x 2 root root 4096 Mar 9 00:55 rc5.d
drwxr-xr-x 2 root root 4096 Mar 9 00:55 rc6.d


Looking in say the /etc/rc3.d directory, things get really interesting! At the risk of providing too much information, you will notice one other thing in the rcX.d directories other than run level... that script links have S or K and # prepended to the script names... this defines the order of execution in the given rcX.d directory. S is for start and K is for stop (i.e. Kill). The # is simple order sequence. This S and K and # sequencing is very important at the operating system level, or if you need your <service> to start or stop and a specific order to work as expected.

For example, if the network service is S10 and your service needs network connectivity, you want it to be S11 or greater, so your service runs after the network is online. Remember how I said the chkconfig values in the INIT INFO header should define the priority of when things execute? Notice below that the link for network service in init.d is in rc3.d and has S10 in front? The S10 is a specific reference back to the chkconfig 10 90 line in the INIT INFO header. So at run level 3 (although not defined in the INIT INFO header as best practice would suggest) is applicable, and the priority order is 10, because of the S10network link in the rc3.d directory. To see this...

# ls -l /etc/rc.d/rc3.d
total 0
lrwxrwxrwx 1 root root 20 Oct 29 11:32 K50netconsole -> ../init.d/netconsole
lrwxrwxrwx 1 root root 17 Mar 9 00:55 S10network -> ../init.d/network


And network is stopped when run level 6 runs... think system shutdown... at priority 90, hence K90network link in the rc6.d directory! Kind of makes sense a bit now right?

# ls - /etc/rc.d/rc6.d
total 0
lrwxrwxrwx 1 root root 20 Oct 29 11:32 K50netconsole -> ../init.d/netconsole
lrwxrwxrwx 1 root root 17 Mar 9 00:55 K90network -> ../init.d/network


Now if you happen to notice that the chkconfig --list command showed network at run level 6 set to off? But there is a K90network link in the rc6.d directory? Well done! The truth is... chkconfig should report that run level 6 for network service/script but it does not! All this means is that if a link exists in a rcX.d directory... that is what counts. Some system developers just create the links in the directories and never use rc-update or chkconfig commands. The chkconfig command has a bug, or for some reason it can see into the rc6.d directory. Shame really but such is Linux life.

Looking at existing script/service files and where they are placed in the various rcX.d directories and what S or K values they have, illustrates what is being done fairly well, once you understand it. Unfortunately, Google almost gives you too much information on this subject. And if all of this is completely over the top in explanation? Blame my German heritage? LOL. Sorry, but figured someone might find this extensive detail educational! I hope I saved someone some major Google-ization!

radiomurf
Posts: 1
Joined: Thu Oct 31, 2013 2:03 pm

Re: Problems running a Python program on startup

Thu Oct 31, 2013 2:13 pm

I know this is an old post... but having had a similar problem, my solution was to specify a user to run the script in the init.d file:

Code: Select all

/bin/su pi /home/pi/twotone.sh
Combined with the strategy to cd into the directory containing the python script this solved the errors for me.

Return to “General discussion”