Крон не выполняется

Вопрос или проблема

У меня есть 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 это не требуется.

Вот что еще стоит проверить, если скрипт все еще не выполняется:

  1. Права на выполнение скрипта: Убедитесь, что скрипт /bkp_db.sh имеет необходимые права на выполнение. Вы можете сделать это с помощью команды:

    chmod +x /bkp_db.sh
  2. Полные пути в скрипте: Внутри вашего скрипта вы используете команды 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
  3. Проверка логов Cron: Cron часто не сообщает об ошибках по умолчанию. Вы можете проверить логи cron, чтобы выяснить, происходят ли какие-либо ошибки. На большинстве дистрибутивов Linux логи cron хранятся в /var/log/syslog или /var/log/cron.

    Используйте следующую команду для просмотра последних записей:

    grep cron /var/log/syslog
  4. Переменные окружения: Cron запускает ваши задачи с минимальным набором переменных окружения. Если ваш скрипт зависит от каких-то специфических переменных окружения, их нужно явно указать в скрипте или передавать вместе с задачей cron.

Если все вышеперечисленные шаги выполнены, и ваша задача все равно не выполняется, попробуйте временно добавить вывод ошибок в ваш скрипт, например, перенаправив вывод:

45 18 * * * /bkp_db.sh >> /path/to/logfile.log 2>&1

Это поможет вам отследить, что происходит, когда cron пытается выполнить скрипт. Если после всех этих шагов проблема не решена, возможно, стоит проверить настройки самого демона cron или обратиться к системным администраторам.

Оцените материал
Добавить комментарий

Капча загружается...