I'm trying to get a script to autostart and hitting some snags.
I know the script works, because I can manually launch it from a terminal window.
I've perused the forums and followed similar advice to put the script in the /etc/rc.d/init.d directory and then create a symlink in the rc5.d directory (S99my_script)
I've even tried appending ". /etc/init.d/myscript" to the .bashrc file

I've managed to get the machine to autologin "myuser" upon startup (that's the owner of the .bashrc file I edited), but still the script won't start when myuser auto logs in.

the system default is set for password protect on screen save so if I simple let that happen, as soon as I exit screen save the script launches, so it almost works ...

I appreciate your input

First determine if the script is even being invoked at all.

Tip top line of the script should be a comment that indicates the shell, and the shell does look at this to determine which shell it's supposed to use. Example:

#!/bin/sh

I always also place in the following lines, and comment in or out depending on whether I need to debug:

#set -x
#set -v

When uncommented, you'll see in the window from which you run, the flow of your script. But when running via the /etc/init.d method you'll not see this output, so this is not relevant, but simply a suggestion for debugging your scripts for when you run them manually.

Next piece of general purpose advice is for every shell command you invoke from within your script, make sure you understand whether or not it is a symbolic link, and what the path for it is:

For instance, if you run "tar" from within your script; outside of your script in a shell window, type "which tar" and determine the path tar is run from, likely /bin/tar and from within your script, always invoke tar as /bin/tar, and not just "tar" because you should not make assumptions about your environment from within the script.

Next advice is to echo information to a log file. /bin/echo "got to this line" >> /home/myuser/script.log

You can also debug the environment from within your script: env >> /home/myuser/script-environ.log

Check the outcome of commands you wonder about:

/bin/tar -tvf myfile.tar
echo "Outcome of the tar operation was $?" >> /home/myuser/script.log

If that number is anything but ZERO, then tar failed for some reason.

Further, I'm not too great at it, I usually have to work at it, but you can output stderr to the log file also:

/bin/tar -tvf myfile.tar &> /home/myuser/script.log

If tar has some sort of problem, it will output the error to your log file.

Using these techniques, you can follow a progression down your script and be able to diagnose better what is wrong. Here's a more encompassing example:

#!/bin/sh
#This is my test script

#Un-comment these to add debug
#set -x
#set -v

# Note the single '>' will create a new script.log file and get rid of the old one
echo "Started my test script" > script.log

env >> script-environ.log
echo "Output my environment" >> script.log

tar -tvf myfile.tar &> script.log
if [ $? -ne 0 ]; then
echo "tar encountered an error" >> script.log
fi

echo "Exiting my test script" >> script.log

exit 0;

1 members found this post helpful.

Which distribution are you using?

the OS involved is CentOS 5.3
I changed the first line in the script from #!bin/bash to #!bin/sh - now when the machine boots, it runs the script momentarily, but then drops through to the desktop (the script launches an image viewer that plays a looped slideshow)
As soon as I open a terminal window, the script runs again.
so now: why the detour to the desktop?

It really depends on what you've written your script to do; when you launch it; whether or not it depends on the Xserver to be there. For instance, if you wrote some script that does a slideshow as you say, then it needs the Xserver to be there. I'd recommend that you run the script from your own personal .bashrc in your home directory versus out of the /etc/init.d tree. S##name = "Start" numbers starting from 01 - 99 in order the linked script. I doubt you want to be before udev, or the Xserver in this case. Hence, if udev is like S03 and Xserver is S20 in the rc5.d directory, then you'd not want to start your script until say S99 just to make sure the rest of the system is up and running first.

But from what I've seen, you auto-login, hence no password, or remembered password and load up your own user's desktop. Is the shell BASH? To check that issue "env | grep SHELL" and you should see something like "SHELL=/bin/bash". That means the BASH shell, and that means in your home directory, /home/<yourusername> you can have a file (likely already do) called .bashrc; which sets up the "your user" specific aliases, paths, and can run scripts for you.

I would run this script out of your own .bashrc and have it be the last thing you do in that file.

From what it sounds like, you can run this script from an Xterminal from within your own login, correct? Then it should work from within your .bashrc.

env | grep SHELL
SHELL=bin/bash

hence, I presume my first line in the script should be #!bin/bash

the symlink (S99myscript)is numbered 99, so that should be run last

indeed there is a .bashrc file in which I've tried to include the name of my script. the question there is: should I include the script statement within the existing conditional IF statement or after?

.bashrc file:

if [ -f /etc/bashrc]; then
. /etc/bashrc
fi

Not
use
ie you have to specify the leading '/', so it knows where to find the bash executable.
Use 'which bash' to check.

HTH

For saving output; 1 = stdout, 2 = stderr
'2>&1' means re-direct output of channel 2 (stderr) to same as chan 1 ie stdout.

some good links
http://rute.2038bug.com/index.html.gz
http://tldp.org/LDP/Bash-Beginners-G...tml/index.html
http://www.tldp.org/LDP/abs/html/

finally getting time to resume my project.

I boot up the PC (Compaq Armada laptop) and it auto logs in myuser.
the slide show starts, but as soon as the desktop fires up, the slide show is interrupted.
if I open a terminal window, the script resumes.

there's a symlink in /etc/rc.d/rc5.d called S99slideshow that points to /etc/rc.d/init.d/slideshow

here's the rest:

[dpf@localhost ~]$ cat .bashrc
# .bashrc

# Source global definitions
if [ -f /etc/bashrc ]; then
. /etc/bashrc
fi
./slideshow
# User specific aliases and functions
[dpf@localhost ~]$
[dpf@localhost ~]$ cat /etc/rc.d/init.d/slideshow
#!/bin/bash
xset s off &
xset s noblank &
xset -dpms &
feh -f /home/dpf/pix/*.* -F -Z -D 5 &
[dpf@localhost ~]$

This
invokes it at system startup

This
invokes it when you login; that's your personal .bashrc.
you only need one or the other...

I commented out the ./slideshow line in the .bashrc file and the script failed to launch upon reboot (I test this by opening a terminal window and issue an xset -q to check the status of the screen saver - it should be disabled if the script runs)

I removed the symlink (S99slideshow) and the script from the /etc/rc.d/init.d directory and re-activated (un-commented) the line in the .bashrc file and the script launches upon reboot and runs up until such time as the desktop displays; then it "hibernates" until I do something, like opening a terminal window, at which time the script resumes.

why is the desktop stepping on the script? do I need to include some sort of DISPLAY command?

imatinkerer
you are aware that CEntOS 5.3 is and has been UNSUPPORTED for a very long time .Since " 2009-10-21"
there have been NO updates to it .

the current ONLY supported 5 is cent 5.6

thank you, John.
I think, perhaps I'll get current and recommence my project.
(BTW - I've managed to make this work using Suse and now am attempting some 'enhancements' to the project that I couldn't get to work in that OS)

ok - upgraded to CentOS version 5.6 pursuant to John's post.
the script starts on boot up but is still getting "stepped on" when the desktop starts.
if I open a terminal window, the script launches (or resumes)
opening any other application simply opens that app, not the script.

I finally resorted to the old adage RTFM ...
the problem was in my script in the form of an amperstand (&) at the end of the line which was causing the command to be executed in the background.

now for some enhancements ...

SINCERE THANKS TO ALL CONTRIBUTORS