CRON - не запускает задачи

[rarog70]

Операционная система UBUNTU-SERVER 12
Работает SQUID
Для отчетов выбран SARG
Сразу оговорюсь для любителей посылать в поиск... искал очень долго, в том числе и на этом форуме,НО результата пока нет. Поэтому излагать буду с самого начала, и, поэтапно то, что делал и к чему пришел.
После установки SARGa настроил его конфиг на выдачу отчетов в /var/www/sarg
После чего проверил нахождение файлов sarg в каталогах:
/etc/cron.daily/
/etc/cron.weekly/
/etc/cron.monthly/
во всех каталогах благополучно находился файл sarg, но с содержимым, соответствующим каждому каталогу:

(Нажмите, чтобы показать/скрыть)

Для каталога daily
#!/bin/sh
if [ -x /usr/sbin/sarg-reports ]; then
  /usr/sbin/sarg-reports daily
fi

Для каталога weekly
#!/bin/sh
if [ -x /usr/sbin/sarg-reports ]; then
  /usr/sbin/sarg-reports weekly
fi

Далее (из одной из статей по теме), я переименовал названия этих файлов из sarg в 0sarg - сделано это для того, чтобы отчеты создавались в самом начале работы cron (в смысле первым из всех файлов в каталоге). Также закомментировал содержимое файла sarg, таходящегося в каталоге /etc/cron.monthly (это для того чтобы при ротации лога к конце месяца отчет не выполнялся дважды.. далее будет понятно почему)

(Нажмите, чтобы показать/скрыть)

Для ежемесячной ротации лога я подправил файлик /etc/logrotate.d/squid

/var/log/squid3/*.log {
        monthly
        compress
        delaycompress
        rotate 2
        missingok
        nocreate
        sharedscripts
        prerotate
                test ! -x /usr/sbin/sarg-reports || /usr/sbin/sarg-reports monthly
        endscript
        postrotate
                test ! -e /var/run/squid3.pid || /usr/sbin/squid3 -k rotate
        endscript
}
как видно именно тут прописана команда выполнения отчета sarg, а уж потом и ротация лога соответственно

Также откорректировал файл /etc/sarg/sarg-reports.conf:

(Нажмите, чтобы показать/скрыть)

        SARG=/usr/bin/sarg
        CONFIG=/etc/sarg/sarg.conf
        HTMLOUT=/var/www/sarg
        PAGETITLE="Отчет по расходу трафика на Server"
        LOGOIMG=/sarg/images/sarg.png
        LOGOLINK="http://192.168.100.2/"
        DAILY=День
        WEEKLY=Неделя
        MONTHLY=Месяц
        EXCLUDELOG1="SARG: No records found"
        EXCLUDELOG2="SARG: End"

Думаю в этом конфиге все понятно.
Поехали дальше.... Вроде как все уже должно работать...НО не работает.... Умные люди в интернете посоветовали поставить на файлы sarg во всех калогах cron атрибут +x, чтож поставил сомандой sudo chmod +x /etc/cron.daily/sarg ну и по этому же типу на остальные..
Проверяем... НЕ запускается задача... При этом если я в консоли даю команду
sudo sarg-reports daily или
sudo /etc/cron.daily/sarg
скрипт выполняется и формируется отчет как положено
Опять же умные люди посоветовали: нужно настроить crontab, даже подсказали как. НАСТРОИЛ:

(Нажмите, чтобы показать/скрыть)

# /etc/crontab: system-wide crontab
# Unlike any other crontab you don't have to run the `crontab'
# command to install the new version when you edit this file
# and files in /etc/cron.d. These files also have username fields,
# that none of the other crontabs do.
SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
# m h dom mon dow user  command
17 *    * * *   root    cd / && run-parts --report /etc/cron.hourly
25 6    * * *   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
47 6    * * 7   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly )
52 6    1 * *   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly )
#
57 23   * * *   root    /etc/cron.daily/0sarg
59 23   * * sun root    sarg-reports weekly
1 0     1 * *   root    sarg-reports monthly

причем это второй вариант.
первый был со строкой 57 23   * * *   root    sarg-reports daily
ни тот, ни другой не работает.
Теперь встал вопрос посмотреть логи (я начинающий пользователь линукса, хотя с компьютерами общаюсь уже давольно давно)
По стандартному пути /var/log я не нашел ничего, напоминающее cron, поэтому начал искать ответ в гугле
Добрый гугль дал ответ, что такое счастье в ubuntu 12 нужно еще и настроить....
и так:
нашел и открыл файл
sudo vi /etc/rsyslog.conf и добавил в конец строчку cron.* /var/log/cron
перезапустил службу лога: sudo service rsyslog restart
Ну вот она радость!! теперь все логи cron записываются в отдельный файл!
Начинаю смотреть:

(Нажмите, чтобы показать/скрыть)

Dec 17 23:57:01 Server CRON[5086]: (root) CMD (sarg-reports daily)
Dec 17 23:57:03 Server CRON[5085]: (CRON) info (No MTA installed, discarding output)

Гугль говорит, что cron не может отправить сообщение об ошибке, по этому и ругается.
Короче говоря... Задача на сегодняшний момент так и не решена. Я уже запутался... ПОМОГИТЕ разобраться с этим демоном!

[OEvg85]

Была подобная проблема у меня  . И потратив кучу времени и перерыв кучу сайтов, понял следующее:
Не стоит изобретать велосипед и редактировать cron'овские файлы вручную, когда для этого специальный инструмент имеется , crontab называется. Команда

Код: (bash) [Выделить]

sudo crontab -e сама откроет файл расписания для root.

У пользователя root и, скажем, user файлы расписания разные и, соответственно, crontab запускать надо для того пользователя, от имени которого задачу запускать планируешь.

Если в официальной документации в самом начале кронтабовского файла стоит

Код: (bash) [Выделить]

#!/bin/sh, оно не просто так . В линуксе вообще ничего просто так не бывает

sarg-reports - обычный bash-скрипт, генерирующий отчеты за указанный период.

В самом sarg-reports уже есть примеры, как его правильно запускать, хотите посмотреть какие, пожалуйста:

Код: (bash) [Выделить]

vi /usr/sbin/sarg-reports
cron обо всех своих действиях рапортует в файл /var/log/syslog (ежели терзают сомнения, глянь туда).

sarg-reports не будет делать отчет, если /var/log/cache.log поврежден.

также sarg-reports не будет делать отчет за неделю/месяц, если логи squid с периодичностью меньше недели/месяца (ищи инфу про logrotate).

Ну вот, впринцыпе, все хитрости , о которых стоит помнить. Стоит добавить, что мой крон работает с такими "настройками": http://pastebin.com/ffsRvjch (это как пример реально рабочего конфига)

ЗЫ. Удачи в освоении cron'а 

[fisher74]

сама откроет файл расписания для root.

А потом ещё пару самых главных действий выполниться: после сохранения изменений и выхода, произойдёт проверка файла расписаний и реконфигурация самого крона (в следующую минуту), что запустит новые расписания в работу.

ТС, Вы реконфигурировали cron после ввода изменений?

И зачем

Код: [Выделить]

57 23   * * *   root    /etc/cron.daily/0sargпри живом

Код: [Выделить]

47 6    * * 7   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly )
Кстати, я не уверен в правомерности словесной замены дня недели (sun) вместо числового значения (0 или 7)

[rarog70]

1. На сколько я понял из пояснений мистера гугла, команда crontab -e - это команда рассписания именно для пользователя, при этом она открывает пустой файл... меня такое не устраивает.... поэтому я и правил /etc/crontab
2. Вызов в расписании weekly по названию дня вроде как является допустимым (опять же по материалам разных сайтов)
3. Я оставил и файл 0sarg во всех каталогах и в crontab Он начинает выполнять, но потом выдает что не может почтой мне отчет направить... короче не выполняет отчет НО при запуске в консоле скрипт выполняется и как sudo sarg-reports-daily и как sudo /etc/cron.daily/0sarg
причем cron пытается его выполнить по всем рассписаниям (я указал разное время в конфиге под спойлером) но увы (((
А вот про реконфигурирование... я читал в нескольких источниках, что не нужно ничего с кроном делать после правки его конфигов, поскольку сразу после правки он сам перепроверяет все рассписания... ну а я, намучившись со всем этим уже не ленюсь полностью перегрузить компьютер, хотя умом и понимаю, что необходимости в этом нет...

[ArcFi]

Кстати, я не уверен в правомерности словесной замены дня недели (sun) вместо числового значения (0 или 7)

Норм.

Код: [Выделить]

LESS='-p \ sun ' man 5 crontab

[fisher74]

1. На сколько я понял из пояснений мистера гугла, команда crontab -e - это команда рассписания именно для пользователя,

Вы правильно поняли. crontab позволяет работать с расписанием вызвавшего его пользователя. Правда Вы не учли, что root тоже пользователь, потому crontab может работать и с его расписаниями.

2. Вызов в расписании weekly по названию дня вроде как является допустимым (опять же по материалам разных сайтов)

Я не спорю, я просто засомневался. arcfi моё сомнение развеял. Спасибо.

А вот про реконфигурирование... я читал в нескольких источниках, что не нужно ничего с кроном делать после правки его конфигов, поскольку сразу после правки он сам перепроверяет все рассписания...

Если Вы просто редактором измените, то откуда cron узнает, что было вмешательство?
Вот если пользоваться crontab-ом, то это всё происходит, он передаёт демону cron команду на реконфиг.

[Yuriy_Y]

Вы правильно поняли. crontab позволяет работать с расписанием вызвавшего его пользователя. Правда Вы не учли, что root тоже пользователь, потому crontab может работать и с его расписаниями.

Однако, вы не учли, что в убунте юзверь root по дефолту отключен, поэтому вы не сможете под ним войти и сделать crontab -e. Если только это не

Код: [Выделить]

sudo suБолее правомерным будет все же редактирование файла /etc/crontab. Откуда крон узнаёт, что файл изменен, я не в курсе, может перечитывает его каждый раз, но это работает. Работало на серверах 10.04, пашет и на 12.04. Правда есть одно большое НО. Чтобы этот файл работал, надо в конце файла в отдельной строке ставить символ # (решетку). Сам воевал с кроном неделю, пока где-то не наткнулся на этот способ.

Даже приведу свой crontab.

(Нажмите, чтобы показать/скрыть)

# /etc/crontab: system-wide crontab
# Unlike any other crontab you don't have to run the `crontab'
# command to install the new version when you edit this file
# and files in /etc/cron.d. These files also have username fields,
# that none of the other crontabs do.

SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

# m h dom mon dow user  command
17 *    * * *   root    cd / && run-parts --report /etc/cron.hourly
25 6    * * *   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
47 6    * * 7   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly )
52 6    1 * *   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly )

00 1-23/1 * * * root sarg-reports today
05 00 * * *     root sarg-reports daily
15 00 * * 1     root sarg-reports weekly
30 00 1 * *     root sarg-reports monthly

0 1,13 * * *    root    ntpdate -d time.nist.gov

#

[fisher74]

Однако, вы не учли, что в убунте юзверь root по дефолту отключен

Однако, Вы ошибаетесь. Пользователь root в ubuntu не отключен. Для него просто отсутствуют аутетификационные данные, что вноисит некоторые ограничения в пользовании его учёткой.

Более правомерным будет все же редактирование файла /etc/crontab.

Не учите "молодёжь" ковырять в носу, они и сами это умеют делать, не хуже Вашего. Именно эти пути ведут к проблемам с системой. Есть специально разработанное приложение для корректировки расписания - вот им и надо пользоваться. Есть возможность использования расписания не root-пользователя, а менее привелегированного - используйте.
Используя расписания привелегированного пользователя, Вы создаёте брешь в системе. Поясню как.

PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
...
00 1-23/1 * * * root sarg-reports today
05 00 * * *     root sarg-reports daily
15 00 * * 1     root sarg-reports weekly
30 00 1 * *     root sarg-reports monthly

Обратите внимание, скрипт sarg-reports ищется в любой директории, предназначенной для исполняемых файлов. То есть достаточно в любую из них (чем в PATH левее директория описана, тем выше вероятность получения результата) затолкать "правильный" скрипт, то система как на ладони, так как этот скрипт будет запускаться каждый час от рута.

Если я где-то не прав - старшие товарищи поправят.

[Yuriy_Y]

Для того, чтоб затолкать "правильный" скрипт в нужную директорию, нужно обладать, как минимум, правами рута, если у вас, конечно, на директории системные не 777 права стоят. Так что не стоит искать опасность там, где ее уже нашли до нас.  Кстати, да, обычно в этом скрипте указывается прямой пусть к исполняемому файлу, как-то вылетело из головы у меня. но работает. :-)

[rarog70]

Ну на счет проблем с безопасностью.... тут система примерно такая: Есть локальная сеть в которой есть 4 ноута, 1 телевизор, 1 принтер и пара телефонов. Так что злоумышленников внутри сети я могу и просто руками удавить... так сказать... да и у пользователей просто ума не хватит ломать сервер, тем более что он на linux (пользуются сугубо игрушками под винду и все...). Сервер подключается к интернету через мегафоновскую свистульку, и раздает интернет в сеть (доступ к серверу из вне закрыт сквидом... ) Ну еще на сервере поднят minidlna... Мегафон убрал безлимитный тариф и поставил ограничение 40 гиг в месяц... вот я и задался задачкой посчитать трафик.... поставил sarg
Теперь по поводу рута и crontab -e..
Я все прекрасно понимаю... но открывая командами crontab -e или sudo crontab -e я все равно получаю пустые файлы... Мое мнение такое - сначала разобраться с общими рассписаниями, а уж потом лезть и в пользовательские. У меня сервер сейчас вообще никак не настроен на пользователей.... есть только один пользователь.... у которого есть возможность пользоваться sudo.. вот и все )))
SQUID - прозрачный... в host прописаны ip адреса ноутбуков и присвоены им имена
SQUID выдает ноутбукам постоянные IP... а для друзей есть диапазон в 10 адресов (это если кто в гости придет...). В общем как то так.
Теперб осталось ftp на этого единственного пользователя настроить, чтобы он подключался при входе к уже расшаренному каталогу.. и дать ему доступ по ftp к серверу из интернета...(чтоб я мог к нему подключаться....).. Но тут вопрос стоял не об этом... вопрос в том, что не выполняются эти скрипты.... и не понятно почему... Правда мне тут уже подкинули идейку... пару дней понаблюдаю и отпишусь... Как мне кажется я нашел проблемку...

[fisher74]

Так что злоумышленников внутри сети я могу и просто руками удавить...

Дело в том, что вырабатывается привычка делать определённые вещи с определённым алгоритмом, а привычка это жуткая штука. Потом нужно будет где-то сделать подобный финт и Вы сделаете это по привычке, потому что там быстрее и Вам удобнее.

но открывая командами crontab -e или sudo crontab -e я все равно получаю пустые файлы... Мое мнение такое - сначала разобраться с общими рассписаниями, а уж потом лезть и в пользовательские.

Правильно. В /etc/crontab лежат расписания нужные системе для её стабильного функционирования. Ваше желание посчитать траффик - уже пользовательские хотелки и на стабильность системы не влияют. Вот и держите мух отдельно, котлеты отдельно. То есть системные расписания пусть и дальше живут в /etc/crontab, а вот Вы свои уже добавляйте в crontab пользователей, пусть даже root. Но это уже будет отдельное расписание от системного.

[martini]

В кронтабе всегда указывайте полные пути к файлам. Как исполняемым, так и прочим (логам, etc.). И будет счастье.

[OEvg85]

Однако, Вы ошибаетесь. Пользователь root в ubuntu не отключен. Для него просто отсутствуют аутетификационные данные, что вноисит некоторые ограничения в пользовании его учёткой.

Однако и Вы ошибаетесь, root'ом тоже можно логиниться. Пример из моей практики: принесли на работу ноут с Ubuntu 9.04 проблема была пустяшная, после проверки диска командой

Код: (bash) [Выделить]

fsck -c /dev/sda1 НЖМД на подопытном стал себя чувствовать нормально. Но любопытство меня просто распирало, очень хотелось посмотреть, что ж там есть интересного . Перезагружаем подопытного, вызываем grub, выбираем режим восстановления, выбираем drop to root shell ну и далее уже в рутовском шеле командой passwd сбрасываем пароль для root'а. Давим enter, перезагружаемся и преспокойненько логинимся root'ом. Может это и нехорошо (ну типа, дополнительная дырочка в системе), но тем ни менее, юзер даже не заметил ничего . Зато я для себя понял, что и root'ом можно логинится. Однако, солидарен с

Именно эти пути ведут к проблемам с системой.

[fisher74]

вызываем grub, выбираем режим восстановления, выбираем drop to root shell

Не путайте режим recovery с рабочим режимом системы.

ну и далее уже в рутовском шеле командой passwd сбрасываем пароль для root'а.

Опять же - Вы не сбросили пароль, а создали. Это разные процедуры. По дефолту у root нет пароля (можете глянуть в /etc/passwd - нет там его), этим и создан запрет его авторизации.

[rarog70]

РЕШЕНО!!!!!
И так... Благодаря Вашим наставлениям я решил присмотреться ко времени выполнения скриптов... забрался в в лог крона (он у меня пишется отдельно от системного) и вот что я там узрел:
1. Выполняеются все скрипты- как из каталогов, так и с кронтаба.
2. Проанализировав предыдущий пункт решил посмотреть как сарг строит свои отчеты и вот что у меня получилось:
  - я запланировал выполнение скрипта на 23:59 и не увидел отчета за прошедшие сутки... после чего запустил скрипт вручную и отчет появился  долго же я смеялся над собой когда посмотрел на часы..... было 0:03, т.е. начались другие сутки и сарг добросовестно сделал отчет ИМЕННО за прошедшие сутки.... и теперь сколько бы я не выполнял этот скрипт... в отчете сарга менялось только время его создания!!!!!
Короче все решилось очень просто:
1. я удалил все записи по поводу сарга из кронтаба.
2. перенастроил стандартную схему выполнения скриптов из каталогов cron.daily, cron.weekly, cron.monthly на такое время:
 DAILY - за день в 0:01
 WEEKLY - за неделю в 0:10
 MONTHLY - за месяц в 0:20
после этого все начало работать как часы))))))
БЛАГОДАРЮ ВСЕХ!!!!! СЧАСТЬЕ ЕСТЬ !!!!