System call from cron Perl script

ralphch has asked for the wisdom of the Perl Monks concerning the following question:

Hi,

I've got a Perl script that writes a text file and then issues a mysqlimport command through a system call:

system "mysqlimport --user=username --password=pwd --silent=true -d database /path/Table.txt";

Whenever I run the script manually from the console as root, it works correctly. However, when it runs at a scheduled time in root's crontab, the mysqlimport system call doesn't get executed (from what I can see, the MySQL table isn't updated).

I would really appreciate any ideas regarding this issue.

Thanks,
Ralph

Comment on System call from cron Perl script Download Code

Replies are listed 'Best First'.
Re: System call from cron Perl script by chibiryuu (Beadle) on Aug 26, 2005 at 03:04 UTC
`$ENV{PATH}` is probably not "right" for the `cron` job. `/etc/profile` (or whatever else the shell sources upon login) probably adds the path to `mysqlimport` to your `PATH`, and `cron` and its children don't run login shells. Try adding `$ENV{PATH} .= ':/path/to/mysql/bin'` to your script.	[reply] [d/l] [select]
Re^2: System call from cron Perl script by duff (Parson) on Aug 26, 2005 at 03:38 UTC
An excellent suggestion. Another way to accomplish much the same thing is to set the path in the crontab entry itself. You can add a line like the following: `PATH=/bin:/usr/bin:/usr/local/bin:/path/to/mysql/bin` [download] somewhere near the beginning of the crontab entry to explicitly set the path for the processes that cron runs. duff	[reply] [d/l]
Re: System call from cron Perl script by jhourcle (Prior) on Aug 26, 2005 at 10:04 UTC
I'll make the following suggestions for calling external programs: Use the full path. You might have set the PATH explicitly, but I have no way of knowing it. Cron can especially change things in subtle ways Always look at the return status. If you expect something to finish, which would be the reason for calling system over exec, you should check the return status. This has been covered multiple times recently. If the program may be printing diagnostic information, you should use backticks or open a pipe. (and possibly redirect STDERR to STDOUT). There are any number of reasons for something like this to go wrong -- And it may have happened before the system call was made. You're looking at the final symptoms -- the table wasn't updated. But was the file written out? Trace the process back, and look for which stage it failed. (you may have done so, but didn't say in your question).	[reply]