>>бог мой, откуда такие берутся?
>>
>>1) РУССКИМ ЯЗЫКОМ написал НЕПРАВИЛЬНО запускать программы из CRONTAB
>>без перенаправления stdout/stderr в лог-файл, можно огрести проблемы.
>>убрал -s, добавь: >/var/tmp/ntpdate.log 2>&1
>>2) grep cron /etc/syslog.conf
>>короче - учите матчасть.
>
>Не - ну я скорее всего тупой (от этого никуда уже не
>деться) но проблема так и висит.
>И все-таки - помогите! не отворачивайтесь!
>
>строка из кронтаб -
>59 * * * * root /usr/sbin/ntpdate 192.168.3.2 >/var/tmp/ntpdate.log 2>&1
>правильно? или все таки я неправльно пользуюсь copy+paste???
>если правильно тогда - почему крон не вносит в логи ничего?
>может быть cron упал?
>смотрю по ps -aux |grep cron (правльно смотрю?)- он на месте!
>файл /var/tmp/ntpdate.log - не организуюется! остальные логи тоже молчат по поводу cron'a!
>
>
>и что такие и что делать?
>lavr - ну доведи до конца!
>
>С уважением z3f.
Еще раз, общие проблемы и ошибки при работе с CRON демоном:
- есть СИСТЕМНЫЙ /etc/crontab и от пользовательских, включая пользователя
root, он отличается ОДНИМ дополнительным полем в котором указывается
ВЛАДЕЛЕЦ запуска:
----------------------- /etc/crontab --------------------------------
#--lavr SYSTEM crontab
#
#--lavr ENVIRONMENT
SHELL=/bin/sh
PATH=/etc:/bin:/sbin:/usr/bin:/usr/sbin
HOME=/var/log
#
#minute hour mday month wday WHO command
#
*/5 * * * * root /usr/libexec/atrun
#
...
#--lavr this is comment
--------------------------------------------------------------------
Системный /etc/crontab редактируется ОБЫЧНЫМ образом - любым редактором
Пользовательские файлы шедулера(расписания), создаются командой:
# crontab -e
# /etc/crontab - root's crontab for FreeBSD
#
SHELL=/bin/sh
PATH=/etc:/bin:/sbin:/usr/bin:/usr/sbin:$HOME/bin
#
#minute hour mday month wday command
#
#*/1 * * * * $HOME/bin/cro
#50 * * * * /sbin/mount -r /dev/ad0s1e/mnt/tmp
#55 * * * * /sbin/umount /dev/ad0s1e /mnt/tmp
в этом файле НЕТ поля WHO: man crontab
Пользовательские файлы расписания создаются: man cron - обычно в
/var/cron/tabs - месторасположения (полный путь) заивисит от OS.
В расписаниях созданных командной crontab - 6'ть полей:
минуты, часы, день_месяца, месяц, день_недели и последнее поле - команда
с параметрами.
Файл расписания созданный командой crontab -e в дополнение к командам
расписания, может содержать настройки среды: SHELL, PATH, MAILTO и тд и тп
- см. man 5 crontab.
Наиболее распространенные ошибки:
- отсутствие настроек среды:
SHELL - каким интерпретатором запускается скрипт
или команда (указанный SHELL должен присутствовать в системе);
PATH - переменная в которой указывается порядок просмотра директорий
для поиска в них исполняемых команд;
MAILTO - переменная указывающая КОМУ будет высылаться MAIL о выполнении
расписания:
MAILTO="" - означает отменить MAIL, если данная переменная НЕ УКАЗАНА
в расписании, cron будет by default отсылать MAIL владельцу расписания
- в файл расписания добавлена команда ПОСЛЕДНЕЙ строкой - она не выполняется, добавить после нее ПУСТУЮ СТРОКУ
- крайне не рекомендуется выполнение по расписанию команды у которой
имеется вывод на stdout, желательно все команды запускать с перенаправлением stderr/stdout в файл или в /dev/null. Формат
перенапаравления зависит от выбранного SHELL'а, для Bourn-Shell (sh)
и bash:
* * * * * /path/command >/path/name.log 2>&1
или
* * * * * /path/command >/dev/null 2>&1
последний пример перенаправляет логи и ошибки в /dev/null если они
нам НЕ НУЖНЫ.
Если команда или утилита написана с поддержкой вызова syslog или записи
в лог-файл, эта реализация может быть выполнена двояко:
- утилита САМА создает лог-файл
- утилита требует ПРЕДВАРИТЕЛЬНОГО создания лог-файла
НЕ ВСЕГДА об этом сказано в MAN, если есть возможность посмотреть
sources - смотрим, если нет такой возможности - смотрим логи cron'а
и создать самостоятельно.
Если поддерживается syslog - man syslog.conf, вставляем нужную строку
для логгирования и выдаем сигнал HUP демону syslogd чтобы он перечитал
изменения файла настроек /etc/syslog.conf:
kill -HUP pid_syslogd (где pid_syslogd - номер процесса syslogd:
ps -axuww | grep syslogd)
Снова вернемся к среде и переменной PATH, ниже два варианта crontab:
------------------ crontab without env -------------------------
#
* * * * * command
* * * * * script
#
----------------------------------------------------------------
переменная PATH не задана и не задан ПОЛНЫЙ ПУТЬ к command и script
- ошибка, они не будут найдены и выполнены
------------------ crontab without env -------------------------
#
* * * * * /path/command
* * * * * /path/script
#
----------------------------------------------------------------
а вот так они будут выполнены, внутри /path/script тоже далжны быть
полные пути к командам и утилитам
------------------ crontab with env ----------------------------
#
SHELL=/bin/sh
PATH=$HOME/bin:$HOME/sbin:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin
#
* * * * * command
* * * * * script
#
----------------------------------------------------------------
выше использование переменных среды для поиска команд, утилит.
Логи:
[alone]~ > grep cron /etc/syslog.conf
cron.* /var/log/cron
[alone]~ >
выше видим что работа cron демона логгируется в файл /var/log/cron
проблемы и диагностику cron демона наблюдаем через этот файл.
Пример с ntpdate: можно запустить со своим лог-файлом, а можно
воспользоваться опцией -s самой утилиты ntpdate:
свой лог (ниже пользовательский crontab):
#
...
* * * * * /usr/sbin/ntpdate ip.add.re.ss >>/var/tmp/ntpdate.log 2>&1
...
#
использование syslog:
- вносим изменения в /etc/syslog.conf:
...
# ntpdate
!ntpdate
*.* /var/log/ntpdate.log
#
- создаем лог-файл с учетом прав владельца запуска и владельца директорий
куда будеи записан лог-файл (данный пример для пользователя root)
touch /var/log/ntpdate.log
- выдаем сигнал HUP демону syslogd чтобы он перечитал конфигурацию
Смотрим логи и проверяем.
PS. "* * * * *" в приведенных выше примерах в файлах crontab заменить
своими реальными значениями.
PPS. Все вышеизложенное написано с листа и без проверки на ошибки или
очепятки.
Вариант для распечатки
OpenNET: Виртуальная конференция (Public)
on
05-Окт-04, 10:00 (MSK)
