3

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?

Improve this question
5
  • 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 Commented Oct 2, 2013 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. Commented Oct 2, 2013 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. Commented Oct 2, 2013 at 8:00
  • @Shadur so I should set spacenavd to something lower than S22? Commented Oct 2, 2013 at 17:06
  • Sounds like a plan. Commented Oct 2, 2013 at 21:33

2 Answers 2

Reset to default
1

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.

Improve this answer
0

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

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.