I have a service that I install as so:

install -m 755 init_script /etc/init.d/spacenavd
cd /etc/rc2.d
ln -s ../init.d/spacenavd S99spacenavd

what the init_script does is start the script:

/usr/local/bin/spacenavd -v

All of this works fine and allows the service to start automatically on startup. However I am having trouble running another script on startup that uses the spacenavd service. This script works normally when I run it manually after login in. However, running it on startup on as so doesn't work when I put it in rc.local.

I do the following in rc.local:

cd /home/filedirec
sudo ./my_script &

This works sometimes and sometimes doesn't. I can't seem to determine what the cause is. What's a good way to trouble shoot?

  • I don't know about spacenavd, but is it possible that it returns and allows init to continue before it's ready to accept connections? Perhaps sometimes rc.local is getting run before spacenavd is fully functional. Try adding a sleep 10 at the top of rc.local and see if the problem persists. Dunno that it's a proper fix, but it should help you troubleshoot – jerm Oct 2 '13 at 4:06
  • Debian has been moving to a dependency-based init setup. Not sure of the exact details off the top of my head. – Shadur Oct 2 '13 at 7:59
  • 1
    ... More importantly, I just checked and rc.local gets run at S22. So you're launching the script well before the server it needs can be reasonably expected to be running. – Shadur Oct 2 '13 at 8:00
  • @Shadur so I should set spacenavd to something lower than S22? – mugetsu Oct 2 '13 at 17:06
  • Sounds like a plan. – Shadur Oct 2 '13 at 21:33

Deja Vu.

Sudo is an interactive program requiring you to provide a password in order to run a command as root (or another user) if you have not recently put in your credentials. The rc.local script is not attached to your console, so you never see it asking for the password.

The rc.local script is also already running as root, so you should remove the sudo command from it.

Better still would be to simply replace all you added with: /home/filedirec/my_script (or /home/filedirec/my_script & if need be). Using the absolute path will make it faster and easier to see exactly what the rc.local script is doing if it needs to be reviewed later, cd and the like are generally better suited to interactive shells.


One thing you can do is start your script in a separate screen session.

For example your rc.local file could look like this:

/usr/bin/screen -dmS my_script bash -c '/home/filedirec/my_script'

Then you can easily 'reattach' the screen after startup and see what's going on with your script. It's also possible to log the output to a file.

If the screen command is not available on your system: sudo apt-get install screen

A tutorial with pictures: screen: Keep Your Processes Running Despite A Dropped Connection

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.