cron job question (for checking kernel updates)

[Rick Stevens]

On 10/02/2013 01:06 PM, Ranjan Maitra issued this missive:
> On Wed, 2 Oct 2013 09:26:32 -0700 Rick Stevens <ricks at alldigital.com>
> wrote:
>
>> On 10/02/2013 08:10 AM, Ranjan Maitra issued this missive:
>>> Hi,
>>>
>>> I have a cron job running which yum updates all my machines once a day.
>>> All of these work fine.
>>>
>>> I also have a cron job which checks for kernel updates every hour and
>>> sends me a message if an updated kernel has been installed. Here is the
>>> relevant script:
>>>
>>> --- begin file called check-kernel.sh in my scripts/yum directory---
>>>
>>> #!/bin/bash
>>>
>>> latestkernel=$(rpm -q kernel |tail -n1|sed -e 's/kernel-//')
>>>
>>> #echo "$latestkernel"
>>>
>>> if uname -a | grep -qv "$latestkernel"; then
>>> notify-send "Kernel UPDATE on ${HOSTNAME}: Running Kernel is $(uname
>>> -r) but lat est installed rpm is ${latestkernel}; REBOOT required"
>>> fi;
>>>
>>>
>>> --- end file called check-kernel.sh ---
>>>
>>> (A bit wordy, I know.)
>>>
>>> I have verified that this is executable and works from the commandline
>>> without any errors.
>>>
>>> I have the following set up via crontab -e:
>>>
>>> 0,15,30,45 * * * * nice -n 19 $HOME/.xplanet/download_xplanet_cloudmap
>>> 5 * * * * nice -n 19 $HOME/scripts/yum/check-kernel.sh
>>>
>>> The first line downloads cloudmaps for use with xplanet and works just
>>> fine (or appears to) and has done so for aeons.
>>>
>>> However, nothing happens (or appears to) for the second line.
>>>
>>> What is wrong here?
>>
>> The most common problem I've seen is that cron jobs typically have very
>> limited paths and the executables you're running (notify-send, uname)
>> may not be in the path the cronjob has. For giggles, do "echo $PATH" as
>> the user the cronjob will run as. Then build a cron job that echos
>> cron's concept of the path:
>>
>> 	#!/bin/bash
>> 	echo $PATH >/tmp/pathecho.txt
>>
>> and have cron run that once as the same user. Look at the data in
>> /tmp/pathecho.txt and I'll bet you'll find its far more restricted than
>> that of an interactive shell.
>
> I tried this: here is what I got --
>
> $ echo $PATH
> /bin:/usr/bin:/usr/local/bin:/usr/local/sbin:/usr/sbin:/home/user/bin
>
> $ cat /tmp/pathecho.txt
> /usr/bin:/bin
>
> Clearly more restrictive as you suggest.
>
> However, what I do not understand is why this does not "work" though. I
> do not understand because notify-send is in /usr/bin as well as in /bin:
>
> $ which notify-send
> notify-send is /bin/notify-send
> notify-send is /usr/bin/notify-send
>
> Both appear to be in the path. So where is the problem?
>
> I will also try the suggestions in the references in Matthew Miller's
> response now.

You could try adding a "set -x" after the shebang line:

	#!/bin/bash
	set -x

That tells bash to print out every expansion. Then change your cron
entry to have a ">/tmp/test.txt 2>&1" at the end:

	5 * * * * nice -n 19 $HOME/scripts/yum/check-kernel.sh >/tmp/test.txt 2>&1

Let the script run, then examine the /tmp/test.txt file to see what bash
doesn't like. Don't forget to remove the "set -x" from the script and
the ">... 2>&1" stuff from the crontab entry when you're done. Odds are
it's a path issue or something that isn't expanding as you think it
would because it's not an interactive shell running the script.
----------------------------------------------------------------------
- Rick Stevens, Systems Engineer, AllDigital    ricks at alldigital.com -
- AIM/Skype: therps2        ICQ: 22643734            Yahoo: origrps2 -
-                                                                    -
-                He who laughs last thinks slowest.                  -
----------------------------------------------------------------------