cron - как выполняются команды - последовательно или параллельно?
скорее всего тупо два раза запустит
только нахера скрипт пускать помесячно, если он уже и так каждый день запускается ?
только нахера скрипт пускать помесячно, если он уже и так каждый день запускается ?
Не понял, какой из них он запустит 2 раза и почему? 
скрипты у тебя разные ?
если разные - то и обозначь их по-разному.
если разные - то и обозначь их по-разному.
Да я собственно по этой статье и читал про крон (по ее копии на опеннете). Там конкретно на мой вопрос ответа я не увидел. Можно конечно пользоваться periodic вместо crontab....
дык вроде разные. читай внимательней.
Этот ввод приведет к тому, что в 23:00 (сегодня, если дело происходит утром, и завтра, если после обеда) последовательно будут выполнены команды who, last и df, и их вывод будет отправлен на электронный адрес пользователя.
я их по-разному и обозначил 
Неверная цитата
Я не про at спрашивал.
Тут очевидно, что будет выполняться последовательно, так как это фактически скрипт написан.
# at 11:00pm
who
last -s -20
df
^D
Этот ввод приведет к тому, что в 23:00 (сегодня, если дело происходит утром, и завтра, если после обеда) последовательно будут выполнены команды who, last и df, и их вывод будет отправлен на электронный адрес пользователя.
Я не про at спрашивал.
Тут очевидно, что будет выполняться последовательно, так как это фактически скрипт написан.
команда1; команда2 # последовательное выполнение
как тебе идея?
как тебе идея?
man оказался наредкость неинформативным
вот ты писдун.
man 5 crontab:
@monthly Run once a month, "0 0 1 * *".
@daily Run once a day, "0 0 * * *".
Можно не использовать @monthly и @daily, а написать в явном виде.
Можно. И что это изменит?
можно разнести их по времени на несколько часов
Где это, в кронтабе указать? Мне надо чтобы один из скриптов только раз в месяц запускался. А другой каждый день - не катит.
Ну в принципе можно. Еще один вариант помимо periodic. Однако хотелось бы знать именно принцип работы крона.
0 6 1 * *.
0 0 * * *.
Я уже понял. Ладно, так и сделаю пожалуй. Однако вопрос с теор. точки зрения все еще волнует.
читает каждую строчку таблицы каждого пользователя смотрит время выполнения, нужные выполняет.
никакой магии вроде нет
никакой магии вроде нет
с теоретической точки зрения запуск нескольких экземпляров скрипта должны обрабатываться самим скриптом.
если скрипт понимает, что он уже запущен - нихуя не делать
если скрипт понимает, что он уже запущен - нихуя не делать
Это РАЗНЫЕ скрипты! Производящие разные задачи, но использующие для этого одни и те же ресурсы. (обновляющие один и тот же файл с инфой).
Я уже понял. Ладно, так и сделаю пожалуй. Однако вопрос с теор. точки зрения все еще волнует.сделай задание раз минуту и раз в час ипроверь по логам прошло ли время между выполнением.
а какая нахуй разница, принцип такой же:
если второй скрипт понимает, что первый уже запущен - нихуя не делать
если первый скрипт понимает, что второй уже запущен - нихуя не делать
для того чтобы скрипты могли понимать - нужно писать/читать флаг в каком-нибудь файле. Или что-то аналогичное.
если второй скрипт понимает, что первый уже запущен - нихуя не делать
если первый скрипт понимает, что второй уже запущен - нихуя не делать
для того чтобы скрипты могли понимать - нужно писать/читать флаг в каком-нибудь файле. Или что-то аналогичное.
последовательно или параллелльно...
как ты думаешь, если у тебя один скрипт будет архивировать огромную базу данных, и закончит через несколько часов - будет ли нормально, что ты указал время для запуска второго скрипа 00.00, а крон запустил его в 06.00 ?
в любом случае они запустятся последовательно, потому что форком нельзя два процесса форкнуть. но в моем предложении слово последовательно не в том же смысле, что в твоем воросе
как ты думаешь, если у тебя один скрипт будет архивировать огромную базу данных, и закончит через несколько часов - будет ли нормально, что ты указал время для запуска второго скрипа 00.00, а крон запустил его в 06.00 ?
в любом случае они запустятся последовательно, потому что форком нельзя два процесса форкнуть. но в моем предложении слово последовательно не в том же смысле, что в твоем воросе
Это РАЗНЫЕ скрипты! Производящие разные задачи, но использующие для этого одни и те же ресурсы. (обновляющие один и тот же файл с инфой).man lockf
последовательно или параллелльно...если второй скрипт переливает результат архивирования на сервер-хранилище, то очень даже хорошо. зависит от задачи.
как ты думаешь, если у тебя один скрипт будет архивировать огромную базу данных, и закончит через несколько часов - будет ли нормально, что ты указал время для запуска второго скрипа 00.00, а крон запустил его в 06.00 ?
man lockfне даёт гарантии на последовательность выполнения.опять же, зависит от задачи.
конкретно в описаной тобой задаче, это хорошо.
но крон работает в многозадачной ОС, какой смысл делать планировщик, который может запустить только одно задание в многозадачной операционке?
но крон работает в многозадачной ОС, какой смысл делать планировщик, который может запустить только одно задание в многозадачной операционке?
если второй скрипт понимает, что первый уже запущен - нихуя не делатьи подумай что из этого выйдет?
если первый скрипт понимает, что второй уже запущен - нихуя не делать
Ты имеешь ввиду оно не определяет что выполнится раньше, а что посже? В общем-то такая задача мною и не ставилась - главное, чтобы они выполнялись не одновременно. Вообще предложение думаю самое правильное.
Можно было бы просто сделать как в скриптах: приписал в конце & - и вторая команда запустится следом за запуском первой. Это было бы намного гибче.
только не &, a &&
& - запуск в фоне
& - запуск в фоне
Однако вопрос с теор. точки зрения все еще волнует.могу с практической сказать. в linux точно параллельно.
>в linux точно параллельно.
родной, какая связь между используемым ядром и испольуемым крон-демоном?
[N] sys-process/bcron (0.09): A new cron system designed with secure operations in mind by Bruce Guenter
[N] sys-process/dcron (3.2): A cute little cron from Matt Dillon
[N] sys-process/fcron (3.0.4-r1): A command scheduler with extended capabilities over cron and anacron
[N] sys-process/incron ~)0.5.7): inotify based cron daemon
[N] sys-process/vixie-cron ~)4.1-r11): Paul Vixie's cron daemon, a fully featured crond implementation
разные демоны по-разному себя ведут, но сомнительно, что есть хоть один, который сериализует запуск разных комманд.
родной, какая связь между используемым ядром и испольуемым крон-демоном?
[N] sys-process/bcron (0.09): A new cron system designed with secure operations in mind by Bruce Guenter
[N] sys-process/dcron (3.2): A cute little cron from Matt Dillon
[N] sys-process/fcron (3.0.4-r1): A command scheduler with extended capabilities over cron and anacron
[N] sys-process/incron ~)0.5.7): inotify based cron daemon
[N] sys-process/vixie-cron ~)4.1-r11): Paul Vixie's cron daemon, a fully featured crond implementation
разные демоны по-разному себя ведут, но сомнительно, что есть хоть один, который сериализует запуск разных комманд.
конкретно в описаной тобой задаче, это хорошо.в общем, он так и так каждую минуту (грубо говоря) просматривает по очереди все таблицы и запускает, что нужно. естественно, не ждёт завершения чего бы то ни было.
но крон работает в многозадачной ОС, какой смысл делать планировщик, который может запустить только одно задание в многозадачной операционке?
надо быть уверенным в том, что он именно подряд пытается запустить, чтобы использовать что-то вроде lockf для действий, которые необходимо выполнять последовательно (например, бэкап и архивирование/отправка его). для гарантии выполнения в нужной последовательности надо разнести во времени хотя бы на минуту.
не даёт гарантии на последовательность выполнения.опять же, зависит от задачи.А мужики-то и не знали!
и подумай что из этого выйдет?
нихуя не делать == нихуя не делать или нихуя не делать некоторое время, а потом проверить еще раз
неужели как в детском саду все разжевывать нужно.
Итогом считаю, что это не задача крона разруливать подобные ситуации. Разруливать нужно в скриптах.
Выдержка из man-а crontab-а
Это и ответ на вопрос: "a lot of jobs are likely to start at once" — то есть запускаются одновременно.
-j jitter
Enable time jitter. Prior to executing commands, cron will sleep
a random number of seconds in the range from 0 to jitter. This
will not affect superuser jobs (see -J). A value for jitter must
be between 0 and 60 inclusive. Default is 0, which effectively
disables time jitter.
This option can help to smooth down system load spikes during
moments when a lot of jobs are likely to start at once, e.g., at
the beginning of the first minute of each hour.
Это и ответ на вопрос: "a lot of jobs are likely to start at once" — то есть запускаются одновременно.
нет, я имел ввиду именно & для реализации текущей функциональности и без & для того, чтобы ожидать завершения предыдущей команды.
Итогом считаю, что это не задача крона разруливать подобные ситуации. Разруливать нужно в скриптах.Согласен. Ибо текущая задача - это проблема приложения. Причем проблема заурядная и решается просто. Автору стоит переписать свои скрипты.
Оставить комментарий
dangerr
на FreeBSD 7 набрал я значитcrontab -e
и написал там 2 строчки:
@monthly /path/to/monthly/script.sh > /dev/null
@daily /path/to/daily/script.sh > /dev/null
Так как оба скрипта работают с одними и теми же данными, то тут же возник вопрос: 1-го числа месяца, когда надо будет запуститься им обоим одновременно, как cron-демон их станет запускать: одновременно или дождется пока закончится первый, затем запустит второй? man оказался наредкость неинформативным