nixp.ru v3.0

26 мая 2017,
пятница,
23:46:57 MSK

DevOps с компанией «Флант»
Longobard написал 3 декабря 2005 года в 23:59 (440 просмотров) Ведет себя как мужчина; открыл 291 тему в форуме, оставил 2499 комментариев на сайте.

Раньше у меня крон работал без проблем. У меня была кучка скриптиков в /etc/cron.daily и подобных папочках, в кронтаб я не лазал. Тут понадобилось заставить скрипты из cron.daily выполняться не в 3 утра, а в 4 утра. Полез в crontab и прописал это:

0  */2  * * *     root /etc/cron.script/ftp-update

1  4  * * *     root /etc/cron.script/emerging

1  4  * * *     root /etc/cron.script/mysql-db-dump

1  4  * * *     root /etc/cron.script/slocate

15 5  * * 6     root /etc/cron.script/squid.cron

Эти скрипты вроде бы выполняются:

03-Dec-05 04:01  USER root pid 17465 cmd root /etc/cron.daily/mysql-db-dump

Но на самом деле они не выполняются. Т.е. если раньше, когда они лежали в /etc/cron.daily, они выполнялись (создавался дамп базы, обновлялся файллист и делался emerge sync), то сейчас они вобще не выполняются (дампов базы нету, файллист старый, синка не было итд). Если положить скрипты в /etc/cron.daily — все равно они не выполняются.

Вот права на файл:

longobard ~ # ls -l /etc/cron.script/

total 24

-r-x——  1 cron cron  114 Окт 30 14:56 emerging

-r-x——  1 cron cron  306 Окт 27 21:44 ftp-update

-r-x——  1 cron cron  196 Авг 31 09:49 icetestscript.sh

-r-x——  1 cron cron 1109 Авг 12 16:19 mysql-db-dump

-r-x——  1 cron cron  211 Сен 18 22:00 slocate

-r-x——  1 cron cron  133 Сен 11  2004 squid.cron

longobard ~ #

Пробовал ставить 777, не помогает.

В чем может быть проблема? Мучал google.ru и опеннет, читал мануал, приставал к Genie. Бесполезно :)

Чего посоветуете?

Заранее спасибо за любые варианты.

Sasha2

А что там насчет того, что в 4.00 по умолчанию вроде updatedb должен работать.

Может тут собака зарыта.

Longobard
Sasha2
А что там насчет того, что в 4.00 по умолчанию вроде updatedb должен работать.

Может тут собака зарыта.

Что значит «по умолчанию"? :)

ну и пусть себе работает, я ему мешаю что ли? Вобще-то updatedb у меня в скрипте slocate включен.

В общем гипотеза лишена смысла. Тогда хотя бы flp-update выполнялся бы раз в час :)

Sasha2

Ну может я и ошибаюсь, а вообще ты не замечал, что в 4.00 (если с системой ничего не делать, имеется в виду не перенастраивать), диск начинает жутко шуршать, что-то все-таки делается в 4.00, ну попробуй на 5.00 один день.

Sasha2

А вот еще из man cron

Additionally, cron checks each minute to see if its spool directory’s modtime (or the modtime on /etc/crontab) has changed, and if it has, cron will then examine the modtime on all crontabs and reload those which have changed. Thus cron need not be restarted whenever a crontab file is modified. Note that the Crontab(1) command updates the modtime of the spool directory whenever it changes a crontab.

Кроме того, cron каждую минуту проверяет, не изменилось ли время modtime (или modtime время у /etc/crontab), и, если это изменение действительно имело место, то тогда cron будет проверять modtime у всех файлов crontabs и перезагружать те, для которых изменение имело место.

Ну дальше не имеет смысла переводить, суть вобщем-то, что у твоих файлов может быть этот modtime меняется, он изх перезагружает, но не выполняет так как перезагружает уже после 4.00.

Longobard

При чем тут конкретное время? даже если твоя гипотеза верна (а она неверна, т.к. ничто не мешает двум ресурсоемким задачам работать параллельно), то выполнялись бы скрипты, которые выполняются раз в час и раз в два часа.

Sasha2

А че спорить, может на опыте проверьт проще.

fly4life
LONGOBARD
Раньше у меня крон работал без проблем. У меня была кучка скриптиков в /etc/cron.daily и подобных папочках, в кронтаб я не лазал. Тут понадобилось заставить скрипты из cron.daily выполняться не в 3 утра, а в 4 утра. Полез в crontab и прописал это:
0 */2 * * * root /etc/cron.script/ftp-update

1 4 * * * root /etc/cron.script/emerging

1 4 * * * root /etc/cron.script/mysql-db-dump

1 4 * * * root /etc/cron.script/slocate

15 5 * * 6 root /etc/cron.script/squid.cron

Эти скрипты вроде бы выполняются:

03-Dec-05 04:01 USER root pid 17465 cmd root /etc/cron.daily/mysql-db-dump

Предлагаю повнимательнее посмотреть на пути к скриптам, записанные в crontab, и на тот путь, который пишется в лог. Затем почесать репу другой рукой и, наконец, найти верное решение своей проблемы ;).

Longobard
fly4life
Эти скрипты вроде бы выполняются:Предлагаю повнимательнее посмотреть на пути к скриптам, записанные в crontab, и на тот путь, который пишется в лог. Затем почесать репу другой рукой и, наконец, найти верное решение своей проблемы ;).

Лог просто старый немного, я потом эти скрипты для надежности переместил в /etc/cron.script из cron.daily :)

Вот свежий лог:

04-Dec-05 04:01 USER root pid 13938 cmd root /etc/cron.script/mysql-db-dump
Genie

тут вся странность в том, что в system-wide файле /etc/crontab должны быть записи вида (man 5 crontab)

EXAMPLE SYSTEM CRON FILE

This has the username field, as used by /etc/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.

# This file also has a username field, that none of the other crontabs do.

# m h dom mon dow user command

42 6 * * * root run-parts --report /etc/cron.daily

т.е. есть дополнительное поле user.

по характеру ошибки, точнее по

04-Dec-05 04:01 USER root pid 13938 cmd root /etc/cron.script/mysql-db-dump

понятно, что cron пытается интерпретировать файл конфигурации как обычный пользовательский. почему так — непонятно.

Longobard
Genie
тут вся странность в том, что в system-wide файле /etc/crontab должны быть записи вида (man 5 crontab)

т.е. есть дополнительное поле user.

по характеру ошибки, точнее по

понятно, что cron пытается интерпретировать файл конфигурации как обычный пользовательский. почему так — непонятно.

У меня написано же

0  */2  * * *     root /etc/cron.script/ftp-update

Юзер указан :)