Как настроить корневое задание крона правильно
Я пытался настроить корневое задание крона, чтобы запустить скрипт Bash как корень, работать в минуту 7,37, каждый час, каждый день месяца, каждый месяц. Этот сценарий расположен в /usr/bin и названный tunlrupdate.sh. Это обновляет DNS Tunlr.
$ ls -l /usr/bin/tunlrupdate.sh
-rwxr-xr-x 1 root root 2133 Sep 24 15:42 /usr/bin/tunlrupdate.sh
Этот сценарий Bash доступен здесь.
При вызове записи сценария, что происходит в журнале, расположенном в /var/log/tunlr.log
Для добавления этого корневого задания крона, я использовал стандарт для crontab корня
sudo crontab -e
И вставленный эти 2 строки в конце. Я ожидаю, что крон запустит скрипт как корень.
# check for updated Tunlr DNS every 30 minutes at the hour + 7 mn and hour + 37 mn
07,37 * * * * root /usr/bin/tunlrupdate.sh
Более поздняя команда sudo crontab -l подтвержденный, что задание крона было вставлено.
Я действительно перезагружал Ubuntu и регистрировался в файле журнала, если задание крона было запущено правильно. Однако в файле журнала нет ничего /var/log/tunlr.log значение задания успешно никогда не запускалось.
Я действительно проверял это, если я запускаю скрипт из командной строки
sudo /usr/bin/tunlrupdate.sh
затем файл журнала обновляется соответственно.
Почему это задание крона не работает как запланировано в моей системе?
ОБНОВЛЕНИЕ 1: Все предлагаемые решения до сих пор не работают. Я благодарю Olli за CLI для списка системного журнала sudo grep CRON /var/log/syslog. Однако я действительно получал ошибку КРОНА
CRON[13092]: (root) CMD ( [ -x /usr/lib/php5/maxlifetime ] && [ -d /var/lib/php5 ]
&& find /var/lib/php5/ -depth -mindepth 1 -maxdepth 1 -type f -cmin +$(/usr/lib/php
/maxlifetime) ! -execdir fuser -s {} 2>/dev/null \; -delete)
с предложенным ПУТЕМ = вставка и использование полного пути от поддерживают функции в сценарии или без этого предложенные решения здесь. Я все еще получаю эту ошибку.
После некоторого поиска я точно определил ошибку в файле /usr/lib/php5/maxlifetime как объяснен здесь: Change #!/bin/sh -e --> #!/bin/sh -x
Затем перечисляя журнал ошибок КРОНА в моей системе
sudo grep CRON /var/log/syslog
Feb 11 18:07:01 Marius-PC CRON[14067]: (root) CMD (root /usr/bin/tunlrupdate.sh)
Feb 11 18:07:01 Marius-PC CRON[14066]: (root) MAIL (mailed 1 byte of output; but got
status 0x00ff, #012)
Я все еще не получаю выполнение сценария удара. На этот раз никакую ошибку не показывают в журнале. Для получения обеспечения, это не было содержанием сценария, я уменьшил сценарий до следующих 3 строк:
#!/bin/bash
LOGFILE=/var/log/tunlr.log
echo $LOGFILE >> $LOGFILE
Я все еще не передаю задание крона. Ничто не записано в файле журнала. Таким образом, даже может быть пустой сценарий, не будет работать в кроне? Я не получаю его. Я, знают, что попытка сценария уменьшила до этих 2 строк:
#!/bin/bash
exit 0
И тем не менее тот же журнал ошибок. Сценарий крона не проходит...
6 ответов
Ну, наконец рабочее решение. В системном журнале я видел повторяющееся и интригующее:
CRON[18770]: (root) CMD (root /usr/bin/tunlrupdate.sh)
Это кажется, что корень не был распознан как cmd. Поскольку я уже использовал крон корня при помощи $ sudo /usr/bin/tunlrupdate.sh. Затем я попробовал исходным сценарием (исправленный для ошибки на дате UNIX cmd: %m, который является месяцем, использовался в течение многих минут, который является %M), следующее (который удаляет корень из строки крона):
$ sudo crontab -e
# check for updated Tunlr DNS every 30 minutes at the hour + 7 mn and hour + 37 mn
07,37 * * * * /usr/bin/tunlrupdate.sh
Это оказалось конечным решением. [Хотя я нашел множество литературы, заявив ошибочную строку с корнем в строке крона. Это было ошибкой].
Если вы хотите запустить скрипт как обычный пользователь :
crontab -e
И добавьте строку:
07,37 * * * * /usr/bin/tunlrupdate.sh
Если вы хотите запустить свой Скрипт как root :
sudo crontab -e
И добавить ту же строку:
07,37 * * * * /usr/bin/tunlrupdate.sh
Одна «проблема» cron - отсутствие переменных окружения (по очевидным причинам безопасности). Возможно, вам не хватает PATH и HOME. Вы можете определить их в скрипте напрямую или в файле crontab.
# check for updated Tunlr DNS every 30 minutes at the hour + 7 mn and hour + 37 mn
PATH=/usr/bin
07,37 * * * * root /usr/bin/tunlrupdate.sh
Вам придется проверять, пока все необходимые переменные не будут определены в соответствии с требованиями сценария.
Сообщения об ошибках Cron обычно - по умолчанию - отправляются по электронной почте. Вы можете проверить, есть ли электронная почта для пользователя root с помощью sudo mail, или просто проверить содержимое /var/mail/root, например, sudo less /var/mail/root.
Если сообщения электронной почты не помогают, также проверьте /var/log/syslog:
sudo grep CRON /var/log/syslog
Как уже сказал Алексис Уилке, у cron есть другой механизм установки переменных среды.
Вашему скрипту требуется
PATH=/sbin:/bin:/usr/bin
для crontab. HOME не должно быть необходимости. Вы должны использовать абсолютные пути в ваших скриптах, например, /bin/date вместо date. Вы можете найти правильные пути для каждой команды с помощью which command_name, например
$ which date
/bin/date
Вы можете добавить эту строку в свой скрипт. Поэтому после того, как вы проверите журналы cron и подтвердите, что ваша работа была выполнена, вы можете получить тот же $ PATH crontabs.
/bin/echo $PATH > /root/path.txt
И, вероятно, лучшее, что вы можете сделать для диагностики проблем в скриптах cron - это получить все переменные окружения SO с помощью команды env в вашем скрипте. Так что просто добавьте эту строку в ваш скрипт. Затем вы можете проанализировать вывод allEvnVars.txt
/usr/bin/env > /root/allEvnVars.txt
Другой прием - направить вывод сценария в какое-то место. Добавление /root/log.log. Таким образом, весь вывод сценария будет сохранен в /root/log.log
07,37 * * * * root /usr/bin/tunlrupdate.sh > /root/log.log
Также вы можете запланировать выполнение сценария каждую минуту, чтобы облегчить тесты и проверки.
*/1 * * * * root /usr/bin/tunlrupdate.sh > /root/log.log
Вы указали в своем вопросе, что сократили скрипт до:
#!/bin/bash
LOGFILE=/var/log/tunlr.log
echo $LOGFILE >> $LOGFILE
У меня уже были проблемы с этим раньше. Оказалось, что это первая линия. Вместо #!/bin/bash я попробовал #!/bin/sh, и это сработало (по крайней мере, для меня).