It runs from command line but not from cron or init script
This question has been posted many times over the years both here at LQ and other sites. Accordingly I'm making this a blog post in the hopes people will find it useful.
When one run things at command line they inherit the environment of the user running them as set by things such as /etc/profile, $HOME/.bashrc, $HOME/.profile and/or $HOME/.bash_profile.
There are many environment variables that can impact a script. You can see all the environment variables you have on a login session by running "set" and/or "env".
Chief among these environment variables is PATH. If you run
"echo $PATH"
at command line you'll see what your PATH variable has set. There are other environment variables that might have an impact if you relied on them as well.
When one runs things in background such as a cron job or init script there is typically a minimal environment set. PATH is apt to have a lot fewer directories in it by default than the average logged in user may have set.
Therefore it is required that you make the script so it either has the environment variables needed or doesn't rely on environment variables. Also the shell intended to run the commands should be specified in the script itself.
It is important to set any needed variables before they are needed later in the script.
So for example one needs to know where the commands they're using are. One can find out by typing
"which <command>"
e.g. "which du" might indicate du is /usr/bin/du and "which awk" might indicate awk is /bin/awk.
Continue to do that for other commands being used. You then should insure the PATH variable within the script itself contains the directories with these commands.
An example script that tells it what shell to use and what variables to set is shown below:
Notice the first line tells it to run the rest of the script using the bash shell. If you wanted to run it as ksh you'd put in the path to that after the "#!". This is called the interpreter line (or "shebang" line) and you should get in the habit of putting it in all scripts whether used in a background cron, init or other. (Note that other interpreter lines can be used for things like perl, php or python scripts but they may use other variable methodologies that aren't typically inherited on login.)
The second line adds /bin and /usr/bin to whatever is already set for PATH variable. (If nothing is set it simply adds these two directories. Notice that each element in PATH is separated by a colon. Remember to do the which for other commands you're using to be sure they're in your PATH as well.
An alternative to adding PATH would be to put in fully qualified directory name each time you invoke a command e.g.
That's easy enough for a small script but in much larger ones it would get cumbersome rather quickly so setting variables is a much better way to go.
When one run things at command line they inherit the environment of the user running them as set by things such as /etc/profile, $HOME/.bashrc, $HOME/.profile and/or $HOME/.bash_profile.
There are many environment variables that can impact a script. You can see all the environment variables you have on a login session by running "set" and/or "env".
Chief among these environment variables is PATH. If you run
"echo $PATH"
at command line you'll see what your PATH variable has set. There are other environment variables that might have an impact if you relied on them as well.
When one runs things in background such as a cron job or init script there is typically a minimal environment set. PATH is apt to have a lot fewer directories in it by default than the average logged in user may have set.
Therefore it is required that you make the script so it either has the environment variables needed or doesn't rely on environment variables. Also the shell intended to run the commands should be specified in the script itself.
It is important to set any needed variables before they are needed later in the script.
So for example one needs to know where the commands they're using are. One can find out by typing
"which <command>"
e.g. "which du" might indicate du is /usr/bin/du and "which awk" might indicate awk is /bin/awk.
Continue to do that for other commands being used. You then should insure the PATH variable within the script itself contains the directories with these commands.
An example script that tells it what shell to use and what variables to set is shown below:
Code:
#!/bin/bash
PATH=$PATH:/bin:/usr/bin
cd /home/db2inst1/sqllib/db2dump
file_size=$(du -k db2diag.log |awk '{print $1}')
if [ $file_size -gt 2 ]
then
. /home/db2inst1/sqllib/db2profile
db2diag -A
mv db2diag.log_2012* /OPT/IBM/DB2/CMSTEMP/db2diag/
chown db2inst1:dbadmin1 db2diag.log
else
echo "No need to move diag.log as size is less"
fi
The second line adds /bin and /usr/bin to whatever is already set for PATH variable. (If nothing is set it simply adds these two directories. Notice that each element in PATH is separated by a colon. Remember to do the which for other commands you're using to be sure they're in your PATH as well.
An alternative to adding PATH would be to put in fully qualified directory name each time you invoke a command e.g.
Code:
file_size=$(/usr/bin/du -k db2diag.log |/bin/awk '{print $1}')
Total Comments 0
