Cron job is not recognizing environment variables

Jon Blanchard · 02-15-2012, 10:47 AM

This is for Red Hat Enterprise Linux running bash 3.2.25(1).

I created a .sh file to collect thread statistics for the application that the server was built for. The shell file is supposed to read the value of one key environment variable, $HCIROOT, at the beginning; it isn't, so the value of all derived vars are missing what should be there. The remainder of the shell script runs as it should, but without accomplishing anything.

The script file references the environment var using $<varname>, which I saw in another job file that runs fine every night. Is there another method that I should be using?

The HCIROOT environment var is set when the server is booted (once per year), so what do I need to do get the shell script to use it?

Thanks in advance for your response.

ShadowCat8 · 02-15-2012, 11:13 AM

Greetings,

Okay, now to start off, let me ask you: Where is the $HCIROOT variable being set from and do you see it in the output when you do the env command?

HTH. Let us know.

Jon Blanchard · 02-16-2012, 09:53 PM

Hmmm...that is a great question.

This is a dedicated interface engine server, so the HCIROOT var should be set at server startup, based on the server startup file. The var does appear when I type env or set.

There is also a .profile in the /home/hci directory, which I assume is run whenever I log in as hci. The HCIROOT var is not set there.

chrism01 · 02-16-2012, 11:12 PM

Quote:

the HCIROOT var should be set at server startup

That would be in a different process env to cron job.
If you want it avail to other processes, it needs to be set eg in /etc/profile, or maybe even in a file.
Each process runs in its own env in *nix; there's no 'global' env as such, although you can 'export' vars down a process tree.
See various references to 'export' here http://linux.die.net/man/1/bash

theNbomr · 02-17-2012, 10:27 AM

There is a fair chance that the variable is defined in a file containing a line something like:

Code:

HCIROOT='some value'

A common idiom in Linux, especially startup scripting, is to use such configuration files by sourcing them:

Code:

#! /bin/bash
. /etc/your_hciroot_config

If you can locate a file that contains such a format, your cron job script can use the same method to set the value of $HCIROOT.

--- rod.

ShadowCat8 · 02-17-2012, 11:06 AM

Quote:

Originally Posted by theNbomr

There is a fair chance that the variable is defined in a file containing a line something like:

Code:

HCIROOT='some value'

A common idiom in Linux, especially startup scripting, is to use such configuration files by sourcing them:

Code:

#! /bin/bash
. /etc/your_hciroot_config

If you can locate a file that contains such a format, your cron job script can use the same method to set the value of $HCIROOT.

Yep, that's right. That is kind of where I was headed with my questions. If you haven't found the file that is setting the variable yet, try this:

Code:

 ~ $ grep -r HCIROOT /etc/*

and see what comes back. If nothing comes back at all, then, while logged in as 'hci', try this:

Code:

 ~ $ grep -r HCIROOT ~/.[A-z]*

And see if it is being set somewhere else in the home directory.

HTH. Let us know.

Jon Blanchard · 02-17-2012, 09:50 PM

The result of

Code:

grep -r HCIROOT /etc/*

was a mass quantity of "Permission denied" and "No such device or address" restrictions on every file that grep tried to search.

The result of

Code:

grep -r HCIROOT ~/.[A-z]*

was a list of references to HCIROOT in the .bash_history file. The birth of this variable is quite the mystery.

Reading theNbomr's statement about the common idiom in Linux gave me the idea to source the .profile from within my getstats2.sh script, instead of sourcing it in the crontab file. Both files are in /home/hci, at least for now. I also decided to manually create the HCIROOT var since, on this engine product, the var is always set to

Code:

$CL_INSTALL_DIR/integrator

and the CL_INSTALL_DIR var is set in /home/hci/.profile.

Let me know what you think. And thanks for all your suggestions.