Perl脚本在crontab中执行时无法写入数据库，尽管如果手动执行则能够写入

Question

I've been wrestling with this issue for awhile now.. and I have tried many solutions, such as:

1. Why can't DBD::SQLite insert into a database through my Perl CGI script?

2. Why do I get sqlite error, “unable to open database file”?

Brief

A few weeks ago, I migrated my server from Laravel 4.0 to another server which is now the latest version of Laravel 5.0.

In the old server, I have this Perl file which is a scraper which I run using a crontab every 30 minutes called getListOfClasses.pl

Using the following crontab command on my OLD server, I would run this:

0,30 * * * * /var/www/loop/storage/scripts/getListOfClasses.pl  >> /var/www/loop/storage/logs/laravel-scraper.log 2>&1

Which executes the scraper in /var/www/loop/storage/scripts/getListOfClassesFromSubjects.pl and writes to my database in /var/www/loop/storage/database.sqlite

After my move, Laravel 5.0 changed the default database location from storage to database, so I edited my crontab to reflect that change as well the database name from:

my $dbFile = '../storage/database.sqlite';

to the new file path location

my $dbFile = '../../database/database.sqlite';

The Issue

If I run my scraper manually at:

/var/www/schedulizer/storage/scripts/getListOfClasses.pl

I am able to scrape just fine. However, if I rely on the crontab to execute the script, I receive the following errors:

DBI connect('dbname=../../database/database.sqlite','',...) failed: unable to open database file at /var/www/schedulizer/storage/scripts/getListOfClasses.pl line 22.

Line 22 is my $dbh = DBI->connect($dsn, $user, $password, {. I don't believe this line of code is relevant - I guess my server has issues writing to that database.

The permissions that my SQLite database has is the following:

-rwxrwxrwx 1 www-data root 8845312 Nov  3 00:05 database.sqlite

The folder in which the database exists has the following permissions:

drwxr-xr-x  5 www-data root       4096 Nov  3 00:05 database

These permission levels all are the same as my old server's permission levels for both the database file as well as the folder.. I've also tried chown and chmod 777 on the database file so it has all the permissions possible. Still no luck.

Any one have clues why?

Answer 1

When testing manually, you probably went to the correct working directory for the script to do the editing. Starting it from any other location would most likely have caused failure as well.

• Use absolute pathes instead of relative to make sure you access the correct and existing directory.
• Include a cd /some/where ; before your command in the crontab. Cron sets your home directory, no matter where the called program sits.

The second proposal is imho the more portable, because it does not require script changes when the location or machine is changed; you simply adapt it in your (machine-specific) crontab.