2

I am using cron to start a program on reboot for my Raspberry Pi (running Raspbian). This program rings a bell hourly based on the current time. When the program is run manually using:

sudo start-bell-ringer.sh

the bell rings as it should and everything works fine. However, if my Pi is rebooted for some reason and the bell-ringer program is instead started automatically by cron, GPIO 18 does not activate and the bell does not ring. That said, I know the program has been started since it is shown in my list of processes and it writes to its log indicating when it has rung the bell. Any ideas why this might be occurring?

I'm thinking that for some reason the program is not getting permissions to use the GPIO. I also toyed with the idea that perhaps it needed more time before starting the process and tried adding a 60 second sleep, but this did not cause the bell to ring after a reboot either. My cron code, located at "/etc/cron.d/bell-ringer" is as follows:

SHELL=/bin/bash
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

@reboot root start-bell-ringer.sh

Note that I am using the Debian features of cron which allow me to indicate the user in a file without having to go through crontab -e as root. Also, start-bell-ringer.sh is in /usr/local/bin along with the c++ program it actually starts, "bell-ringer".

  • I had a quick look but couldn't find the run as other user Debian extension in the various mans. Have you got a link? Does it work if you just use the root crontab? – joan Feb 12 '15 at 11:31
  • This page contains an identical cron man page as the one on my version of Raspbian. Logging into root and using crontab results in the same erroneous behavior. – Swan Feb 12 '15 at 23:34
2

In a curious turn of events, probably due to an issue in my program, the following change in the cron file fixes the problem

SHELL=/bin/bash    
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

@reboot root start-bell-ringer.sh && start-bell-ringer.sh

Since cron was correctly starting my program in the first place, my manual starting of the program was effectively starting it twice as well. start-bell-ringer.sh checks to see if my bell-ringer program is running and kills it if so, then starts the bell-ringer process. In essence, in order for my program to access the GPIO correctly, it has to start, get killed, and then start again. I believe this is a bug in my C++ code related to how I access the GPIO ports. The stop gap measure I have implemented will work for now though.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.