Autorun c executable on boot

Question

I tried following the many autorun-suggestions given on different forums, but I'm still struggling with it.

I've got a C code that runs on the Pi - logs temperature and sends the data to the serial port to a 4D systems screen continuously [there's an endless while loop in my code]. I need to get this to run on startup automatically.

C code name: temp_logger.c
Executable: temp_logger

Method 1
I added the following line:

sudo /home/pi/temp_logger/./temp_logger &  

to /etc/rc.local

On reboot, the code just runs once and locks up the serial line which means I can't use it again.

Method 2
I then created a bash script called temp_logger.sh in /etc/init.d with the right header from /etc/init.d/skeleton and placed the following line towards the end:

sudo /etc/init.d/./temp_logger &

[I moved my executable to the init.d folder for this.]
I set the right permissions and ran: sudo update-rc.d temp_logger defaults. On reboot, nothing happens and the serial line gets locked.

Method 3

sudo crontab -e  
@reboot /home/pi/temp_logger/./temp_logger &  

Code executes just once and hangs the serial line. Any help would be appreciated.

Answer 1

Please check the link on how to run a command on boot using cron. That should help you to start your binary on boot.

How to write a initial script and let it run a command automatically

sudo crontab -e
@reboot /home/pi/temp_logger/temp_logger

This should be sufficient to run your cron job and I don't think you need that

"./temp_logger"

Also you don't need the "&". This is generally used to put a process in background. The only thing that you need to take care should be proper logging to debug in case of failures. I hope you have done that.

Answer 2

I tried following the many autorun-suggestions given on different forums

To be blunt, if this is the case you've managed to hopscotch a "blind leading the blind" trail, because if you are still using sudo inside /etc/rc.local, you might as well have read nothing at all. Literally nothing. Honestly. Basic fundamental: It's run by init as root.

I am not accusing you of any particular incompetence, BTW. This is one of the absolute worst handled topics around, and one of the unfortunate realities about the Raspberry Pi world is it is a bit insular, so there are certain viral misconceptions about linux fundamentals that incubate and spread within it in a way that is sometimes clearly distinct from the broader linux user base.

Another basic, although it is easy to miss because cron's actual man page documentation is totally ambiguous about it (the word "background" never being mentioned), is that cron starts things via fork and exectute -- i.e., in the background. So you do not need &.

A thing about doing things you don't need to do is they may or may not have unintended side effects. As far as I know, using sudo in rc.local or & in a crontab is harmless, but since it certainly won't do any good, don't do it, and regard any blog, tutorial, etc. which shows this as expressing a profound ignorance regarding how things work.

• Here's some suggestions about logging and debugging boot scripts.

• Here's a simple example of how to use /etc/rc.local, although it focuses someone else's issue, it includes some reasonable general guidelines.

• Here's an explanation of how to start a service via systemd. Again, it focuses on someone else's issues, but if you skip down to "Instead, capsulize your thing in its own startup script..." you should be able to extrapolate. Although this seems like the most complicated method, it is also the most flexible and provides you with a bit more tracking potential than the others (more than nothing, that is, although since rc.local is run by systemd you can a get version of this that way) via systemctl status [whatever].

I can't emphasize enough the value of using shell wrapper scripts, which is explained particularly in the last one; they don't need to be more than a few lines, but they allow you to arrange things like logging, forking/backgrounding, and setting the environment (including $PATH) in a cleaner, simpler way.

Note none of my suggestions involve cron. This is a bit of a personal bias; I think it is deceptively simple, and dependent on init anyway (so ultimately more convoluted). The real purpose of cron is to run intermittent finite tasks, not persistent system services. That's init (on Raspbian init is systemd BTW, if you have not hit upon this point yet).

If after all this you are still having problems, you need to throw more debugging output into your process and find out exactly where it stops. A boot service is an awkward context to debug problems in, but unfortunately also one where they may show up when not otherwise evident.