[alibek]

Есть (будет) задача, которую нужно будет запускать каждые 19 минут.

Можно ли такой интервал настроить в планировщике?

Или запускать скрипт каждую минуту и в самом скрипте считать количество запусков?

[pppoetest]

*/19 * * * * /path/to/mega/script

[alibek]

/19 не подойдет, это не "каждая 19-ая минута", а "минута, кратная 19" (или "каждая 19-ая минута часа").

Такой план будет срабатывать в 00:19, 00:38, 00:57, 01:19, 01:38 и т.д.

А мне нужно, чтобы он срабатывал в 00:19, 00:38, 00:57, 01:16, 01:35 и т.д.

[YuryD]

 Скрипт наверное. slip 19*60 в  бесконечном цикле.

[Alex/AT]

Ну так что мешает нагенерить пачку строк с нужным временем запуска для кронтаба? :)

[YuryD]

Только что, Alex/AT сказал:

Ну так что мешает нагенерить пачку строк с нужным временем запуска для кронтаба? :)

 В произвольные моменты от запуска? Скрипт со слипом решает. Запущаете в авторане скрипт с бесконечным скриптом, внутри слип нужной задержки, и запуск , возможно с контролем того, что не успело завершиться. Даже на шелле обычном решается.

[alibek]

6 минут назад, Alex/AT сказал:

Ну так что мешает нагенерить пачку строк с нужным временем запуска для кронтаба?

Уж больно много таких строк потребуется, более тысячи.

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

[Alex/AT]

Ну да, тоже верно. Проще внутри скрипта время трекать.
Еще есть идиотский вариант - каждый запуск считать следующее время запуска и править кронтаб. Но это идиотский вариант. Потому что если запуск будет пропущен, будут проблемы - т.е. нужно это ещё учитывать и т.п. 

 

Самый удобный вариант имхо тот самый с запуском каждую минуту - не требуется висящего в фоне процесса. Единственное что, он чуть увеличит нагрузку.

[Alex/AT]

20 минут назад, alibek сказал:

...

Тут ещё другой вопрос: а с чем связан такой выбор интервала? Просто если оно всё настолько жёстко завязано на те самые 19 минут - не вызовет ли это проблем где-то, например, при пропуске интервала.

А если завязано не настолько жёстко - то спокойно можно написать например вызовы так:

0,19,38,57 0,6,12,18 * * *
16,35,54 1,7,13,19 * * *
13,32,51 2,8,14,20 * * *
10,29,48 3,9,15,21 * * *
7,26,45 4,10,16,22 * * *
4,23,42 5,11,17,23 * * *

При этом один из вызовов каждые 6 часов будет происходить через 18 минут, а не 19, это по сути минимальная погрешность. Всего 6 строк, и строго определённые моменты запуска каждый день.

[pppoetest]

1 час назад, alibek сказал:

/19 не подойдет, это не "каждая 19-ая минута", а "минута, кратная 19" (или "каждая 19-ая минута часа").

Такой план будет срабатывать в 00:19, 00:38, 00:57, 01:19, 01:38 и т.д.

А мне нужно, чтобы он срабатывал в 00:19, 00:38, 00:57, 01:16, 01:35 и т.д.

Хмм, странно, считал иначе.

[DDR]

Проще в системд добавить сервис с таймером

$ cat /etc/systemd/system/myscript.service
[Unit]
Description=My script
Conflicts=shutdown.target
After=local-fs.target
Before=shutdown.target

[Service]
Type=oneshot
ExecStart=/opt/scripts/myscript.sh


$ cat /etc/systemd/system/myscript.timer
[Unit]
Description=My script run every 19 min

[Timer]
OnBootSec=19min
OnUnitActiveSec=19min

 

[adeep]

11 часов назад, alibek сказал:

/19 не подойдет, это не "каждая 19-ая минута", а "минута, кратная 19" (или "каждая 19-ая минута часа").

*/19 - каждая 19-я минута

 

19 * *  - в 19ю минуту каждого часа

 

"При указании диапазона можно пропускать некоторые его значения, указав шаг в форме / число Например: ``0-23/2'' для поля Fa час означает запуск команды через два часа (по стандарту V7 пришлось бы указывать ``0,2,4,6,8,10,12,14,16,18,20,22 )'' Шаг можно указывать также после звёздочки: ``каждые два часа '' соответствует значению ``*/2''

[st_re]

1 час назад, adeep сказал:

*/19 - каждая 19-я минута

 

нет.. "каждая 19 минута часа", а не просто каждая 19-я минута.

Это не тоже самое, если интервал не кратен часу.

 

fgrep each_19 /etc/crontab
*/19  * *   *   *   user      /bin/date >> /tmp/each_19

 cat /tmp/each_19
Sun Oct 29 00:19:01 MSK 2017
Sun Oct 29 00:38:01 MSK 2017
Sun Oct 29 00:57:01 MSK 2017
Sun Oct 29 01:00:01 MSK 2017
 

 

Как нетрудно заметить между 3 и 4 прошло совсем не 19 минут.

 

еще веселее, если хочетста "каждые 59 минут"

*/59  * *   *   *   user  /bin/date >> /tmp/each_59

cat /tmp/each_59

Sun Oct 29 00:00:01 MSK 2017

Sun Oct 29 00:59:01 MSK 2017
Sun Oct 29 01:00:01 MSK 2017
 

 

упс... :) всего 1 минута.

 

тоже самое относится к часам (*/13 - каждый 13 час суток, т.е. 00 и 13 часов, потом снова 00) и прочим */x

 

 

[snvoronkov]

16 часов назад, DDR сказал:

Проще в системд добавить сервис с таймером

А если это RHEL/CentOS < 7, (Free|Open|Net)BSD, Debian < 8... 

 

Просит автор решение для крона, значит имеет на то резоны.

 

Зы: По теме добавить нечего.

[Tau]

Через at ставить задачу на следующее выполнение?

[nuclearcat]

*/1 и внутри скрипта поставить проверку когда скрипт выполнялся последний раз :)

Скажем первый раз делать touch /tmp/myscript_flag , а потом проверять mtime этого файла, если >=19 запускаем остальное

[YuryD]

20 минут назад, nuclearcat сказал:

*/1 и внутри скрипта поставить проверку когда скрипт выполнялся последний раз :)

Скажем первый раз делать touch /tmp/myscript_flag , а потом проверять mtime этого файла, если >=19 запускаем остальное

 Сурово :) Проще скрипт бесконечный при старте запустить,  с внутри слипом на 19минут. Проверить процесс, и убить если не завершился ещё, прибить, и снова запустить. У обычного шелла есть все возможности, если у админа есть некое желание это сделать в виде скрипта.

[pppoetest]

54 минуты назад, YuryD сказал:

Проще скрипт бесконечный при старте запустить,  с внутри слипом на 19минут.

Плохой путь, нужен будет какой нить monit скрипта, если упадёт.

[alibek]

Нет, бесконечный цикл это плохо, там много подводных камней (например остановить задание).

Сделал ежеминутный запуск. Единственное - не считаю число запусков, а смотрю время прошлого прогона (как в примере nuclearcat) - так проще.

[Susanin]

Запускать каждую минуту, переводить время в формат unix time. Выпонять фунционал только если количество минут делиться на 19 без остатка.

Без доп. файлов.

Ребуто-независимо.

[alibek]

Да, тоже неплохо.

[YuryD]

В 29.10.2017 в 22:55, alibek сказал:

Нет, бесконечный цикл это плохо, там много подводных камней (например остановить задание).

Сделал ежеминутный запуск. Единственное - не считаю число запусков, а смотрю время прошлого прогона (как в примере nuclearcat) - так проще.

 В цикле - я же писал, про проверить статус запущенного, и если надо, то прибить, или ждать, сообщая админу письмом. В бесконечном цикле легче контролировать и статусы запущенного, и количество циклов, без внешних файлов и глобальных переменных. Реализуемо практически даже на shell.  В частности во freebsd у меня таких скриптов крутится несколько. А killall -9 procname прибьет все копии запущенные с гарантией. При запуске - контролировать статус завершения, если кода завершения нету - значит по pid прибивать киллом. Есть хорошая древняя книжка про программирование на shell. Остальные шеллы еще больше умеют.

[alibek]

Нет, не вижу смысла в таких самодельных решениях, если есть более подходящий cron или systemd.

Остановить задание это только один из возможных моментов, вообще их намного больше.

Я делал ранее повторяющиеся задачи в бесконечном скриптовом цикле, это лишние заботы на ровном месте.

[YuryD]

6 минут назад, alibek сказал:

Нет, не вижу смысла в таких самодельных решениях, если есть более подходящий cron или systemd.

Остановить задание это только один из возможных моментов, вообще их намного больше.

Я делал ранее повторяющиеся задачи в бесконечном скриптовом цикле, это лишние заботы на ровном месте.

 Это и есть уних-стайл. Как лучше умеешь, так и делай. Пингвиноидов не касается :)

[myth]

19 часов назад, alibek сказал:

Остановить задание это только один из возможных моментов

Просто запускать как сервис и все.