I use Debian Lenny on an embedded device

uname -a
Linux device 3.4.0 #83 Sun May 26 17:07:14 CEST 2013 armv4l GNU/Linux

I have a C code (say my_C_program) that calls a board specific binary file (via system("spictl someparameters") ) called spictl to use SPI interface

user:~# ls -al /usr/local/bin/spictl
lrwxrwxrwx  1 root staff      24 Jun  9  2011 spiflashctl -> /initrd/sbin/spiflashctl

if I run my code (my_C_program) from the command line

user:~# /user/sbin/my_C_program

the spictl is executed without problem and outputs data from the SPI interface.


I need the program to be run when the board is powered. Therefore, I add /user/sbin/my_C_program line before the exit 0 at/etc/rc.local. When the board is powered, the my_C_program is executed and spictl is executed but the SPI interface does not output any data.

I tried to run the program via /etc/init.d/ script on this link. The script works fine and it executes the my_C_program, the program executes the spictl successfully (as system() return value says), but the SPI interface does not output any data!

ls -l /usr/sbin/my_C_program
-rwxrwxrwx 1 root root 61713 Jun 28  2013 /usr/sbin/my_C_program

top shows that the program is run as root

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                                          
 1095 root      20   0  2524 1140  924 R  4.2  1.8   0:00.35 top                                                                              
 1033 root      RT   0 35092  34m 1852 S  3.0 56.5   0:14.06 node 


if I execute the my_C_program on terminal, the program calls the spictl (via system(spictl someparameters)) and it is executed without any problem. But if I run my_C_program through /etc/rc.local or /etc/init.d script, then spictl does not work as it supposed to be. I suspect that it has something to do with the root privilege. When I execute the program on the terminal (as root) all works fine. But I guess /etc/rc.local and /etc/init.d somehow runs the program with a lower privilege. I could not really solve the difference between executing a command from the terminal as root or executing the program via /etc/rc.local or /etc/init.d/ script. If you also think that it is a privilege problem, could you please explain how can I ensure that init.d script or rc.local would run the program with the highest privilege. Or what could be the issue?

Please note that the problem/question is not SPI related.

P.S. in order not to have unnecessary conversation like "oh Debian lenny is too old, you should use wheezy etc.", the board has armv4l processor and as the producer says it does not support wheezy because of some processor instructions.

  • 2
    It's probably a path issue. Try to use the full path to the spictl binary. – Marco Jul 24 '13 at 14:23
  • Marco, it makes a lot sense! thank you I am going to try it now – Angs Jul 24 '13 at 14:26
  • 1
    +1 I actually like the P.S. especially since you're talking about init stuff that hasn't changed in about 30 years. – msw Jul 24 '13 at 14:31
  • the problem is solved, as Marco pointed out, it was a path problem. thanks a lot for the help. and it is good to know alternative possibilities as msw points out – Angs Jul 24 '13 at 14:57

You're C executable probably requires some environment variables to be set to function. For example the env. variable $PATH or $LD_LIBRARY_PATH. There also other variables such as $HOME which won't be set until a user has logged in.

This last one might be necessary for your app to access config files and/or log files, for example.


To investigate what's going on, redirect the output of your program (especially the errors) to a file.

/usr/sbin/my_C_program >/root/my_C_program.out 2.>&1

If that doesn't give any clue, break out the artillery: install strace.

strace /usr/sbin/my_C_program -o /root/my_C_program.from_etc_local.strace

Also run the program from the command line and compare the traces. Even if you don't understand what most of the lines are doing, the first few lines where the traces differ should give a clue. Ignore most differences that only concern integer values as these are typically due to different load addresses and focus on where the system calls differ.

Most likely, the program is looking for some file which is fails to find because it is invoked from a different directory, or because PATH or some other environment variable isn't set to the value that you expect when you start the program from /etc/rc.local.

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.