Ubuntu 9.10: how do I troubleshoot a startup script that doesn't appear to run?

Question

I've created a bash script 'foo'. I've made that script executable with

chmod+x 

and added it the the start-up by running

sudo update-rc.d foo defaults 80

Despite that, it doesn't appear to be working at startup. Is there a way to have my script echo messages to a log? Or is there some log that would record events/errors for this?

atm, I feel like I'm flying blind and don't really know how to troubleshoot this.

As requested, here is the content of my script:

#!/bin/bash
modprobe uinput
/home/dane/dev/mangler/run.sh /home/dane/dev/mangler/dane/keys.js

the run.sh command executes program kbd-mangler.exe. When running the following in a gnome-terminal it works:

~/$ sudo bash custom_keys.sh

Solution 1

At the beginning of your script, add this line:

exec > /tmp/debug-my-script.txt 2>&1

Reboot. Now look at that file in /tmp - it should tell you what's going on.

By the way, in init.d scripts I tend to use commands with full path (/sbin/modprobe). I've been burned so many times by the restricted PATH used by those scripts, I make no assumptions now. :)

By the way, good Bash programming links:

http://mywiki.wooledge.org/BashFAQ

http://mywiki.wooledge.org/BashPitfalls

http://mywiki.wooledge.org/BashGuide

Solution 2

Take a look at the logger command.

Add a line like this to the beginning of your script:

logger "foo started"

for a simple message to be added to /var/log/syslog as an indication that your script is doing something.

Solution 3

Does the script work if you run it with sudo? If the script is setup properly the most common error I have seen relates to not setting up the environment properly.

For example it is a good practice to either set explicitly set your PATH at the start of the script or to use the full path for any commands you run.

Also is 80 the level you really need? Are you depending on something that hasn't started yet?

Does your script adequately check error levels of things you run and then respond appropriately. Good scripting and programming requires that you watch for and handle errors properly.

Put some echo status statements into your script and watch carefully as your system boots. Using logger helps since you can send output to syslog.

You could add the set -x to the first line of the script and a sleep 120 as the last line and then watch for errors. This will basically echo every statement as it is being executed to your screen and then it will wait a couple minutes so you have an opportunity to read and identify problems.

Solution 4

Just to add to what has been suggested.

I would also verify that the symlink /etc/rc2.d/S80foo was created and is linked correctly. If the file foo didn't exist update-rc.d should have given you an error but doesn't hurt to double check.

View more solutions

Comments

[Zoredache]

Can you post the contents of your script?

[Zoredache]

I see your script is referencing your home directory. Is that folder mounted and available at that point in the boot process? Have you enabled encrypted home directories?

[lemiant]

Unfortunately, I don't know how to verify any of this since I'm missing a tool to troubleshoot. I can't seem to get any type of output from things leading up to or during the execution of this script. So I don't know the context in which it's running .

[lemiant]

Will the output of echo always appear on the screen during boot? Or do I have to boot in a special way? sleeping is a good idea +1

[Zoredache]

I guess I was assuming you where running this on a server which would I don't think has any splash screens enabled. If this is a desktop system with a GUI then a lot of the startup messages are likely to have been hidden.

[lemiant]

Unfortunately it's a desktop system. Can I write to a log in my script? Or even better, are there any logs that will automatically capture start-up errors (like not being able to find the command because of an encrypted home directory)?

[Dennis Williamson]

Add the logger command in your script to send messages to a log file as you might use echo for debugging output to the terminal.

[Dennis Williamson]

Add a line like this to the beginning of your script: logger "foo started" for a simple message to be added to /var/log/syslog as an indication that your script is doing something.

[lemiant]

This works well. It will work in this case too. I accepted Andrei's because it let me put all the output in one place with one line of code. Your logger method mixes output into the syslog and must be filtered with grep. Regardless, +1

[bomben]

@Pauseduntilfurthernotice. Your second comment should be an answer!