Cron Job Failures With A Perl Script Containing Astro::Time

Home » CentOS » Cron Job Failures With A Perl Script Containing Astro::Time
CentOS 2 Comments

Everyone,

I am building a gateway server with a new : CentOS Linux release
7.3.1611 (Core)  with 3.10.0-514.2.2.el7.x86_64 kernel.

Everything was going find, but I was not able to get a particular cronjob to function properly that contained a perl script with Astro::Time as an include file. Astro::Time was installed with the use of the cpan module downloaded from the CentOS repositories.

The error message I get in the logs is :

Can’t locate Astro/Time.pm in @INC (@INC contains:
/usr/local/lib64/perl5 /usr/local/share/perl5
/usr/lib64/perl5/vendor_perl /usr/share/perl5/vendor_perl
/usr/lib64/perl5 /usr/share/perl5 .) at /usr/local/bin/s.bkup.degw3.prl line 12. BEGIN failed–compilation aborted at /usr/local/bin/s.bkup.degw3.prl line 12.

Line 12 is the line in the perl scrip that contains :

use Astro::Time;

The script works find from the command line, but will not work at all in a cron job.

After I reviewed the previous posts on this mail list about CentOS 7
cron job problems I was motivated to change the PATH statements in the
/etc/crontab file to include all of the PATH’s in my root environment while using a terminal interface.

/etc/crontab file :
SHELL=/bin/bash
#PATH=/sbin:/bin:/usr/sbin:/usr/bin PATH=/usr/lib64/qt-
.3/bin:/root/perl5/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bi n:/root/bin QT_PLUGIN_PATH=/usr/lib64/kde4/plugins:/usr/lib/kde4/plugin MAILTO=root

The original /etc/crontab file was :
SHELL=/bin/bash PATH=/sbin:/bin:/usr/sbin:/usr/bin MAILTO=root

Unfortuantely I am still not able to get this script to work.

Has anyone else had this problem and found a solution?

Greg Ennis

2 thoughts on - Cron Job Failures With A Perl Script Containing Astro::Time

  • [snip]

    This almost always points to something in the environment.

    Where did Astro::Time actually get installed? Check the above paths to see if it is actually there, or whether cpan put it somewhere else. If it put Astro::Time elsewhere, you will need to add a PERL5LIB export to your crontab file (or better, make a bash wrapper, point cron to that, and put the PERL5LIB variable there).

    If you put it in crontab, you should get the current value from your shell, and put that into crontab (verify it looks reasonable first).

    echo $PERL5LIB
    # or env |grep PERL5LIB

    If you don’t have PERL5LIB set, you can take the paths you currently have defined (see your path list above) and add the path to Astro::Time to that.

    –keith

  • [snip]

    This almost always points to something in the environment.

    Where did Astro::Time actually get installed?  Check the above paths to see if it is actually there, or whether cpan put it somewhere else.  If it put Astro::Time elsewhere, you will need to add a PERL5LIB export to your crontab file (or better, make a bash wrapper, point cron to that, and put the PERL5LIB variable there).

    If you put it in crontab, you should get the current value from your shell, and put that into crontab (verify it looks reasonable first).

    echo $PERL5LIB
    # or env |grep PERL5LIB

    If you don’t have PERL5LIB set, you can take the paths you currently have defined (see your path list above) and add the path to Astro::Time to that.

    –keith

    Keith,

    Thanks for your reply. I am not totally sure what I did when I
    installed the CentOS 7 on this machine, but I did identify that I had inappropriately installed perl-File-HomeDir.noarch which I normally do not use.  

    This was the only thing that I identified that was done differently. I yum removed perl-File-HomeDir.noarch, but the problem in using Astro::Time from a cron job or an account different than root was not fixed. I finally wrote a wrapper that sets the environment variables to the same command line env variables as root so that the root cron backup routines would work.

    I spent about 8 hours trying to fix this problem, but finally the wrapper bypass was the only thing that worked.  I not totally sure if perl-File-HomeDir.noarch was the culprit, but I will certainly be careful not to install it again.

    Thanks for your help !!!

    Greg