Вопрос или проблема
У меня есть cron в моем crontab
45 18 * * * root /bkp_db.sh
Но он не работает. Он не выполняется. Что я делаю не так?
Внутри моего скрипта:
NOW=$(date +"%Y-%m-%d")
mysqldump -u root apps_db > bkp_apps/dump_app1_$NOW.sql
mysqldump -u root app_db2 > bkp_apps/dump_app2_$NOW.sql
zip -r bkp_apps/bkp_apps_$NOW.zip /var/www/myapps/public_html
Ваш персональный файл crontab должен выглядеть так
45 18 * * * /bkp_db.sh
Существует несколько файлов crontab, каждый из которых имеет немного другой формат. Персональные файлы crontab, редактируемые с помощью crontab -e
, не содержат имени пользователя.
man crontab
говорит,
Существует один файл crontab для каждого пользователя в директории
/var/spool/cron/crontabs. Пользователям не разрешается редактировать файлы
в этой директории напрямую, чтобы гарантировать, что только пользователи,
разрешенные системой для выполнения периодических задач, могут их добавлять, и только синтаксически правильные crontab будут записываться там. Это обеспечивается тем, что
директория доступна для записи только группе crontab и конфигурированием команды crontab с установленным флагом setgid для этой конкретной группы.
Но если вы прочитаете man cron
, вы также увидите,
Кроме того, в Debian, cron читает файлы из директории /etc/cron.d.
cron обрабатывает файлы в /etc/cron.d так же, как файл /etc/crontab (они следуют специальному формату этого файла, т.е. включают поле пользователя). Однако они независимы от /etc/crontab: они не наследуют, например, настройки переменных окружения от него.
Это изменение специфично для Debian, смотрите примечание под DEBIAN SPECIFIC ниже.
Ответ или решение
Ваш cron-задача, записанная в crontab, не выполняется по нескольким причинам. Предположим, что ваш crontab выглядит следующим образом:
45 18 * * * root /bkp_db.sh
Однако при использовании команды crontab -e
для редактирования crontab файла для пользователя, не следует указывать имя пользователя перед командой, так как пользовательские cron-задачи сохраняются отдельно. Таким образом, правильная запись, которую вы должны использовать, выглядит так:
45 18 * * * /bkp_db.sh
Если вы используете /etc/crontab
или файл в /etc/cron.d
, то синтаксис будет правильный, так как там указывается имя пользователя. Однако для пользовательского crontab это не требуется.
Вот что еще стоит проверить, если скрипт все еще не выполняется:
-
Права на выполнение скрипта: Убедитесь, что скрипт
/bkp_db.sh
имеет необходимые права на выполнение. Вы можете сделать это с помощью команды:chmod +x /bkp_db.sh
-
Полные пути в скрипте: Внутри вашего скрипта вы используете команды
mysqldump
иzip
, не указав их полные пути. В cron-задачах важно использовать полные пути к выполняемым программам. Найдите полный путь к вашим командам с помощьюwhich
, например:which mysqldump which zip
После этого измените ваш скрипт так, чтобы он использовал полные пути:
NOW=$(date +"%Y-%m-%d") /usr/bin/mysqldump -u root apps_db > /path/to/bkp_apps/dump_app1_$NOW.sql /usr/bin/mysqldump -u root app_db2 > /path/to/bkp_apps/dump_app2_$NOW.sql /usr/bin/zip -r /path/to/bkp_apps/bkp_apps_$NOW.zip /var/www/myapps/public_html
-
Проверка логов Cron: Cron часто не сообщает об ошибках по умолчанию. Вы можете проверить логи cron, чтобы выяснить, происходят ли какие-либо ошибки. На большинстве дистрибутивов Linux логи cron хранятся в
/var/log/syslog
или/var/log/cron
.Используйте следующую команду для просмотра последних записей:
grep cron /var/log/syslog
-
Переменные окружения: Cron запускает ваши задачи с минимальным набором переменных окружения. Если ваш скрипт зависит от каких-то специфических переменных окружения, их нужно явно указать в скрипте или передавать вместе с задачей cron.
Если все вышеперечисленные шаги выполнены, и ваша задача все равно не выполняется, попробуйте временно добавить вывод ошибок в ваш скрипт, например, перенаправив вывод:
45 18 * * * /bkp_db.sh >> /path/to/logfile.log 2>&1
Это поможет вам отследить, что происходит, когда cron пытается выполнить скрипт. Если после всех этих шагов проблема не решена, возможно, стоит проверить настройки самого демона cron или обратиться к системным администраторам.