Скрипт Perl не может записать в базу данных при выполнении в crontab, несмотря на то, что может писать при выполнении вручную

Question

Скрипт Perl не может записать в базу данных при выполнении в crontab, несмотря на то, что может писать при выполнении вручную

1

Я уже давно борюсь с этой проблемой.. и я пробовал много решений, таких как:

краткое

Несколько недель назад я перенес свой сервер с Laravel 4.0 на другой сервер, который теперь является последней версией Laravel 5.0.

На старом сервере у меня есть этот файл Perl, который скребок, который я запускаю с помощью crontab каждые 30 минут, называется getListOfClasses.pl

Используя следующую команду crontab на моем OLD- сервере, я запустил бы это:

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

Который выполняет скребок в /var/www/loop/storage/scripts/getListOfClassesFromSubjects.pl и записывает в мою базу данных в /var/www/loop/storage/database.sqlite

После моего перемещения Laravel 5.0 изменил местоположение базы данных по умолчанию из storage в database, поэтому я отредактировал свой crontab, чтобы отразить это изменение, а также имя базы данных:

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

к новому пути к файлу

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

Проблема

Если я запустил свой скребок вручную:

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

Я умею хорошо царапать. Однако, если я полагаюсь на crontab для выполнения сценария, я получаю следующие ошибки:

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

Строка 22 - это my $dbh = DBI->connect($dsn, $user, $password, {. Я не верю, что эта строка кода релевантна - я думаю, что у моего сервера есть проблемы с записью в эту базу данных.

Разрешения, которые имеет моя база данных SQLite, следующие:

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

Папка, в которой существует база данных, имеет следующие разрешения:

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

Эти уровни разрешений все совпадают с уровнями моего старого разрешения сервера как для файла базы данных, так и для папки. Я также пробовал chown и chmod 777 в файле базы данных, чтобы он имел все разрешения. Еще не повезло.

Кто-нибудь знает почему?

theGreenCabbage 03 нояб. 2015, в 06:52

Источник

2

От какого пользователя запускается cron? В отличие от пользователя, который запускает скрипт вручную?
JRD 03 нояб. 2015, в 06:05
0

@JRD Как мне это проверить?
theGreenCabbage 03 нояб. 2015, в 06:05
0

Хорошо, вы редактируете файл crontab -e с помощью crontab -e или другим способом? Также можно опубликовать запись crontab на новом сервере?
JRD 03 нояб. 2015, в 06:11
0

Вы можете добавить оператор ведения журнала, например print STDERR "UID=$< EUID=$> ", qx/pwd/; и проверьте, что вы получите от работы cron (обычно вы получаете STDERR по почте). Qx qx/pwd/ aso проверяет текущий рабочий каталог на случай, если он должен был измениться.
mbethke 03 нояб. 2015, в 06:12
0

пара быстрых советов - убедитесь, что папка имеет разрешения на выполнение для пользователя и что файл также имеет разрешения на выполнение для пользователя. Вы не показали сообщение об ошибке, которое может быть полезным (т. Е. Модуль perl не найден или есть проблемы с разрешениями для файлов или каталогов). Имеет ли исполняемая среда perl доступ к модулям от имени этого пользователя или модуль был установлен в другом ENV?
Peter Scott 03 нояб. 2015, в 07:17
2

Используйте абсолютные пути вместо относительных, чтобы обеспечить доступ к правильному и существующему каталогу. Включить cd /some/where ; перед вашей командой в crontab. Это корни crontab или www-данных? В последнем случае su для www-data и попробуйте выполнить файл, из которого он запущен.
syck 03 нояб. 2015, в 10:10
0

Может быть, первое «../» в $ dbFile излишне (в старом значении был только один «../»)? Попробуйте протестировать скрипт с полным путем к файлу базы данных в переменной $ dbFIle.
drvtiny 03 нояб. 2015, в 12:52
2

При запуске из cron есть три ключевых различия: пользователь, среда, путь. Проверьте все это, как вы ожидаете.
Sobrique 03 нояб. 2015, в 14:17
0

@mbethke, я вставлю это в свой Perl-скрипт? Можно ли направить сообщение об ошибке в мой файл журнала, специфичный для скребка?
theGreenCabbage 03 нояб. 2015, в 16:12
0

@PeterScott Насколько я знаю, это все сообщения об ошибках, которые я получил (не удалось подключить одно)
theGreenCabbage 03 нояб. 2015, в 16:12
0

@syck Уууууууууууу ... С помощью абсолютных путей сработало! Я так удивлен !! Я думал, что это не будет иметь никакого значения, учитывая, что выполнение его вручную не вызывает проблем !! Спасибо! Не могли бы вы опубликовать ответ, чтобы я мог пометить его как правильный?
theGreenCabbage 03 нояб. 2015, в 16:17
0

Готово =) ........
syck 04 нояб. 2015, в 10:33

Показать ещё 10 комментариев

Теги:

php

mysql

sqlite

perl

crontab

1 ответ

Ещё вопросы

От какого пользователя запускается cron? В отличие от пользователя, который запускает скрипт вручную?
Хорошо, вы редактируете файл crontab -e с помощью crontab -e или другим способом? Также можно опубликовать запись crontab на новом сервере?
Вы можете добавить оператор ведения журнала, например print STDERR "UID=$< EUID=$> ", qx/pwd/; и проверьте, что вы получите от работы cron (обычно вы получаете STDERR по почте). Qx qx/pwd/ aso проверяет текущий рабочий каталог на случай, если он должен был измениться.
пара быстрых советов - убедитесь, что папка имеет разрешения на выполнение для пользователя и что файл также имеет разрешения на выполнение для пользователя. Вы не показали сообщение об ошибке, которое может быть полезным (т. Е. Модуль perl не найден или есть проблемы с разрешениями для файлов или каталогов). Имеет ли исполняемая среда perl доступ к модулям от имени этого пользователя или модуль был установлен в другом ENV?
Используйте абсолютные пути вместо относительных, чтобы обеспечить доступ к правильному и существующему каталогу. Включить cd /some/where ; перед вашей командой в crontab. Это корни crontab или www-данных? В последнем случае su для www-data и попробуйте выполнить файл, из которого он запущен.
Может быть, первое «../» в $ dbFile излишне (в старом значении был только один «../»)? Попробуйте протестировать скрипт с полным путем к файлу базы данных в переменной $ dbFIle.
При запуске из cron есть три ключевых различия: пользователь, среда, путь. Проверьте все это, как вы ожидаете.
@mbethke, я вставлю это в свой Perl-скрипт? Можно ли направить сообщение об ошибке в мой файл журнала, специфичный для скребка?
@PeterScott Насколько я знаю, это все сообщения об ошибках, которые я получил (не удалось подключить одно)
@syck Уууууууууууу ... С помощью абсолютных путей сработало! Я так удивлен !! Я думал, что это не будет иметь никакого значения, учитывая, что выполнение его вручную не вызывает проблем !! Спасибо! Не могли бы вы опубликовать ответ, чтобы я мог пометить его как правильный?

syck · Accepted Answer · 2015-11-04T12-16-00.000Z

При тестировании вручную вы, вероятно, перешли к правильному рабочему каталогу для сценария для редактирования. Запуск его из любого другого места, скорее всего, также вызвал сбой.

Используйте абсолютные шаблоны вместо относительного, чтобы убедиться, что вы обращаетесь к правильному и существующему каталогу.
Включить cd/some/where ; перед вашей командой в кронтабе. Cron устанавливает домашний каталог, независимо от того, где находится вызываемая программа.

Второе предложение - это более переносимое, поскольку оно не требует изменений скриптов при изменении местоположения или машины; вы просто приспосабливаете его в своем (машинный) crontab.