Было бы здорово иметь такую фичу к 3.1...

Created attachment 2202 [details]
load-sensitive cronjob wrapper

пример использования:
--- /etc/cron.daily/slocate.cron на основе исходного из Black Cat 6.02
/usr/local/bin/relax -l 0.1 -t 3 --once /usr/bin/slocate -u -e /tmp -e
"/var/tmp,/usr/tmp,/afs,/net,/proc"
---

Тж. https://lists.altlinux.org/pipermail/devel/2008-February/069577.html

Тж. http://www.opennet.ru/tips/info/1620.shtml (taskset -b)

Просьба заценить http://git.altlinux.org/people/mike/packages/?p=idlewrap.git в качестве обёртки для запуска updatedb, makewhatis и osec.  Скрипт несовершенен и может быть доработан в сторону /etc/sysconfig/idlewrap, но будто работает.

2mike: Посмотри service-0.5.17-alt1 и vixie-cron-4.1.20060426-alt4-3-g3f23a87,
это проект дистрибутивного решения.
Для тех cronjob'ов, запуск которых можно вообще пропустить при определённых условиях, нужен какой-то другой подход.

Дим, почитав 0.5.18, мне вспомнилась та картинка о проекте создания качелей под деревом.  Фундамент для пакетного и администраторского наведения порядка по nice/ulimit для сервисов понравился (много откуда гвозди или вынимание единственного nice value из sysconfig можно будет вынимать), но:

- я-то предлагал не сервисы оборачивать, а задачи -- именно потому,
  что обобщить все cronjob'ы до одних требований обычно не получается
  (например, osec важнее slocate и тем более makewhatis);
- предложенная обёртка по имени idlewrap проста как двери (и даже 
  не проверяет ionice -t, согласен) -- но при этом содержит ещё одну
  мелкую приятную фичу, которая тут оказалась выплеснута с младенцем:
  idle CPU scheduling (schedtool -D), и одну побольше -- про питание.

Попробую проверить на себе и стенде (в т.ч. стареньком железе и используя anacron), хватит ли для crond NICE_PRIORITY=10 или idle prio заметно лучше.

Доработать idlewrap до модульных тестов, конечно, можно -- но постарался сделать эту обёртку возможно тоньше и проще (подумав ещё, конфигурационный файл решил не делать).  Кажется, можно выкинуть форки на fgrep и cut.

2 legion: спасибо за участие!

(In reply to comment #7)
> - я-то предлагал не сервисы оборачивать, а задачи -- именно потому,
>   что обобщить все cronjob'ы до одних требований обычно не получается
>   (например, osec важнее slocate и тем более makewhatis);

Но все эти задачи не должны иметь большой nice и ionice, если только запуск задач по cron не прямая задача сервера... но и это укладывается в идею общего выставления лимитов на crond.

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

> - предложенная обёртка по имени idlewrap проста как двери (и даже 
>   не проверяет ionice -t, согласен) -- но при этом содержит ещё одну
>   мелкую приятную фичу, которая тут оказалась выплеснута с младенцем:
>   idle CPU scheduling (schedtool -D), и одну побольше -- про питание.

Я не стал добавлять schedtool в limited, потому что меня смутил его man-страница:

SCHED_IDLEPRIO [ patch needed ] SCHED_IDLEPRIO is similar to SCHED_BATCH, but was explicitely designed to consume only the time the CPU is idle. No iteractive boosting is done. If you used SCHED_BATCH in the -ck kernels this is what you want since 2.6.16

Я согласен с Димой, что задача по пропуску некоторых cronjob'ов отличается от задачи лимитов и это нужно ещё придумать как реализовать. Я бы вынес её отдельным багом.

Лёш, я вот про этот сюжет: http://www.intuit.ru/department/se/intuml/1/01_02.gif

Эта бага повешена аккурат о той задаче, которая отличается от решённой.  И детский набросок решения для _исходной_ задачи (вместе с более современным наброском idlewrap) тоже доступен.  Осталось поправить запускалки кронджобов.

Если охота повесить багу для успешно (IMHO) реализованного в service-0.5.17+ -- ну... можно :-)  И сразу закрыть.

---

schedtool(8) можешь особо не смущаться -- там о том, что в -ck семантика IDLE была присуща классу BATCH; смержен CFS scheduler был ещё в 2.6.23 и на M41/2.6.25 -D работает.

Для M40/2.6.18 можно сделать откат на -B или просто оставить nice 10..20, это не столь важно -- а ionice -c3 там уже работало.

http://lkml.indiana.edu/hypermail/linux/kernel/0603.1/0930.html
http://kerneltrap.org/node/8059

---

В limited поддержка schedtool и ionice мне _пока_ кажется бесцельной, хотя для больших систем возможность организовать affinity и отодвинуть третьестепенные сервисы совсем в фон может быть и интересной -- это лучше поговорить с support@ и заказчиками, эксплуатирующими такие системы.

(In reply to comment #9)
> Эта бага повешена аккурат о той задаче, которая отличается от решённой.  И
> детский набросок решения для _исходной_ задачи

Ещё раз, в исходной задаче описано две проблемы:
1. запуск cronjob'ов с высоким приоритетом;
2. пропуск не существенных cronjob'ов при определённых условиях.

Первую задачу limited решает. Я предлагал, вторую задачу вынести в отдельный баг, а не первую :)

> (вместе с более современным
> наброском idlewrap) тоже доступен.  Осталось поправить запускалки кронджобов.

Мне кажется задача #2 не так проста и не глядя запускать cronjob'ы через idlewrap нельзя. Вместе с тем, критерии какие нужно/не нужно запускать зависят от машины.

> schedtool(8) можешь особо не смущаться

Добавить его не проблема. Будет ещё опциональная ручка.

> В limited поддержка schedtool и ionice мне _пока_ кажется бесцельной, хотя для больших
> систем возможность организовать affinity и отодвинуть третьестепенные сервисы
> совсем в фон может быть и интересной -- это лучше поговорить с support@ и
> заказчиками, эксплуатирующими такие системы.

Мне кажется это полезной возможностью. Без этого у нас были только /etc/security/limits.

Лёш, niceness -- это не приоритетность, а обратная величина -- пусть будет "скромность" :)

---

Одна часть разницы задач -- в гранулярности объекта: сервисы vs задачи из-под одного (двух дублирующих, неважно) из них.  При этом вариант "занайсить весь anacron" предлагался как "на скору руку".

Вы с Димой решили более фундаментальную задачу в этом же направлении, но её применимость к _этой_ баге ограничивается самым дубовым из изначально предложенных вариантов -- "nice anacron" с поправкой на современные технологии(tm) в виде ionice.

---

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

Что конкретно этому мешает?  Или какая для updatedb и makewhatis зависимость приоритета от машины? (для osec -- уже выслушал и принял мнение rider@)

В крайнем случае /etc/cron.*/* обычно %config(noreplace), если вдруг откуда-то такая зависимость вылезет.  А как вылезет -- так и будем систематизировать, поскольку вероятность этого IMHO пренебрежимо мала.

---

Добавлять поддержку в индивидуальные cronjob-ы предлагаю так:
http://git.altlinux.org/people/mike/packages/?p=slocate.git;a=commitdiff;h=218cfbfd25b937fcb81722978980a4963d31276f

Ау.  Патчи приветствуются или игнорируются?  В community@ опять напомнили про эту неприятность.

ping -- поставил 20100909, опять makewhatis колотится об диск и тормозит первую загрузку системы.  Какой вообще сермяжный толк с anacron, портящего жизнь по утрам?

Поправочка: ionice -t критично, иначе будем почём зря обламываться под ovz.  Отправил idlewrap-0.2.1-alt1.

Сочтём, что уже сделано в нынешних service и vixie-cron или idlewrap.
У меня вопрос отпал (возможно, после переезда на SSD лет десять назад).