incorrect value for HOSTNAME executed as cron job

[Julian]

Hi.

I have a problem with a script in perl that obtain value of HOSTNAME
environment variable.

!/usr/bin/perl

# Autoflush
$|=1;

do("/home/sixsl/scripts/constantes.pl");

$lock_dir="/var/dbsync";

$host_actual=$ENV{HOSTNAME};

....

When I executed the script manually from the shell it obtain correct
value for hostname (harpo for this case). But when I put the script in
the cron the perl obtain incorrect value, it gets localhost. Cron job
is executed with the same user that I executed the script from the
shell.

The cron daemon is vixie cron. The perl version is 5.8.0. The Linux
box is RedHat 9.0.

Julian.

 

[Glenn Jackman]

$host_actual=$ENV{HOSTNAME};

...

When I executed the script manually from the shell it obtain correct
value for hostname (harpo for this case). But when I put the script in
the cron the perl obtain incorrect value, it gets localhost. Cron job
is executed with the same user that I executed the script from the
shell.

Surprise, you get a different environment in cron than in your
interactive shell. All you get in a cron environment is HOME, PATH
and a couple of others. Try running 'env' as a cron job.

You could obtain the hostname by the hostname command, or you could
source your profile before running your script.

 

[pkent]

When I executed the script manually from the shell it obtain correct
value for hostname (harpo for this case). But when I put the script in
the cron the perl obtain incorrect value, it gets localhost. Cron job
is executed with the same user that I executed the script from the
shell.

Cron jobs run in a very, very, impoverished environment. I've never
known any cron daemon to load the user's .profile (or whatever) before
executing the crontab entry. The crontab lines are also probably
executed with the bourne shell, not the user's preferred login shell.

Look in your crond manpage to see what env vars are set - or possibly in
the headers of the emails that you get from cron (something like
X-Cron-Env: lines). Failing that, maybe temporarily add a crontab entry
to run a command like 'env'?

If you want any other env vars set you need to do it yourself - we use a
wrapper script that sources and sets all the things a job could need
e.g.:

*/5 * * * * /usr/local/scripts/cron_run /path/to/file arguments

P

 

[Robin]

Hi.

I have a problem with a script in perl that obtain value of HOSTNAME
environment variable.

!/usr/bin/perl

# Autoflush
$|=1;

do("/home/sixsl/scripts/constantes.pl");

$lock_dir="/var/dbsync";

$host_actual=$ENV{HOSTNAME};

...

When I executed the script manually from the shell it obtain correct
value for hostname (harpo for this case). But when I put the script in
the cron the perl obtain incorrect value, it gets localhost. Cron job
is executed with the same user that I executed the script from the
shell.

The cron daemon is vixie cron. The perl version is 5.8.0. The Linux
box is RedHat 9.0.

Julian.

probably something with your crontabs.... or check the paths.
-Robin

 

[Joe Smith]

probably something with your crontabs.... or check the paths.
-Robin

No, it is not Julian's crontab. It the way the cron daemon
handles _everybody's_ crontab files.

rh9# grep -i hostname /etc/bash* /etc/csh*
/etc/bashrc: PROMPT_COMMAND='echo -ne
"\033]0;${USER}@${HOSTNAME%%.*}:${PWD/#$HOME/~}\007"'
/etc/bashrc: PROMPT_COMMAND='echo -ne
"\033_${USER}@${HOSTNAME%%.*}:${PWD/#$HOME/~}\033\\"'
/etc/csh.cshrc: set prompt=\[`id -nu`@`hostname -s`\]\$\
/etc/csh.login:setenv HOSTNAME `/bin/hostname`

Those files are executed by /bin/login but not by /usr/sbin/crond.

Therefore it is up to the person who created the crontab entry to
ensure that the appropriate 'rc' files have been processed in a cron job.
-Joe

 

[Julian]

probably something with your crontabs.... or check the paths.
-Robin

I edited crontab file and added HOSTNAME setting and now works. Thanks
for the help to all.

Julian

 

[Uri Guttman]

J> I edited crontab file and added HOSTNAME setting and now works. Thanks
J> for the help to all.

boy did you pick the wrong poster to listen to. you solution will work
but not be portable. wait until you need to deploy this to more
machines.

uri