Здравствуйте!
Хочу сделать демон, который бы запускал форком скрипты (для начала) с заданной периодичностью, например, каждые 2,5 , 40 минут и 7 часов.
В крон можно каждый повесить, но не хочется сами скрипты трогать, надежнее свой демон сделать который в будущем бы с БД сам настройки вытаскивал бы и передавал рабочим скриптам.

В голову пока пришло бесконечный цикл с 2мя счетчиками, но как-то совсем по идиотски выглядит, да и в будущем... мало ли, кратности не будет. хоть 1-2 секунды и роли то никакой не играют.

правильно себе представляю так: есть 3 счетчика которые генерируют сигналы - отлавливать их и соответственно обрабатывать. Только не знаю способен ли баш на подобное?

Прошу подсказать как лучше решить задачку => направить куда нужно :)

• bash deamon,phpcoder, 12:43 , 18-Мрт-11
• bash deamon,anonymous, 16:24 , 18-Мрт-11
  • bash deamon,Moeng, 22:31 , 18-Мрт-11
    • bash deamon,anonymous, 14:47 , 19-Мрт-11
    • bash deamon,Аноним, 16:56 , 19-Мрт-11
    • bash deamon,ACCA, 19:52 , 19-Мрт-11
    • bash deamon,pavlinux, 00:35 , 25-Мрт-11

Я бы использовал крон. Свой велосипед ни разу не надёжнее, как правило.

> Хочу сделать демон, который бы запускал форком скрипты (для начала) с заданной
> периодичностью, например, каждые 2,5 , 40 минут и 7 часов.
> В крон можно каждый повесить, но не хочется сами скрипты трогать, надежнее
> свой демон сделать который в будущем бы с БД сам настройки
> вытаскивал бы и передавал рабочим скриптам.

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

> почему вам кажется, что надо трогать скрипты при повешении в крон?

1. скрипты нужно сконфижить дл запуска, а данные взять с БД и ТХТ логов
2. в перспективном будующем еще подвесить пару
3. время запуска тоже хотель бы менять через бд
4. это уже к существующей системе доработка

Если в частности вам не приходилось такое использовать, то это еще не означает что это никому не нужно.
И не собираюсь всю ОС переводить на это, но плодить в кроне тоже не хочется кучу скриптов, которые в частности к ОС не имеют значения.
Кроме того это еще и не на 1 сервере делаться будет, и лепить велосипед к каждому скрипту это уж точно самый дибильный вариант!

>> почему вам кажется, что надо трогать скрипты при повешении в крон?
> 1. скрипты нужно сконфижить дл запуска, а данные взять с БД и
> ТХТ логов
> 2. в перспективном будующем еще подвесить пару
> 3. время запуска тоже хотель бы менять через бд
> 4. это уже к существующей системе доработка
> Если в частности вам не приходилось такое использовать, то это еще не
> означает что это никому не нужно.

Я не могу понять, какую задачу вы решаете *на самом деле*, по тем кусочкам информации, что вы уже привели.  Удачи.

1,2,3,4 - И? Там только с 3 придётся повозиться - "остальное из коробки"

> И не собираюсь всю ОС переводить на это, но плодить в кроне
> тоже не хочется кучу скриптов, которые в частности к ОС не  имеют значения.

Что за бред? В огороде - бузина?

> 1. скрипты нужно сконфижить дл запуска, а данные взять с БД и
> ТХТ логов
> 2. в перспективном будующем еще подвесить пару
> 3. время запуска тоже хотель бы менять через бд
> 4. это уже к существующей системе доработка

1. Напиши скрипт, который умеет брать данные из БД и TXT логов. Напиши второй скрипт,
   который умеет запускать конфигуратор, потом конфигурируемого. Второй скрипт отдай cron.
2. Потом подвесишь столько, сколько в crontab влезет.
3. Возьми hcrond (правда нафига?)
4. см.№1 и №2.

[...]
> Кроме того это еще и не на 1 сервере делаться будет, и
> лепить велосипед к каждому скрипту это уж точно самый дибильный вариант!

Положить два новых скрипта на два сервера - менее дебильный вариант, чем переписывать на shell стандартную подсистему Unix.

Если же серверов сотни, то тоже не нужно переписывать Autosys или Tivoli - они решают кучу проблем, о которых ты пока даже не догадываешься.

> 3. время запуска тоже хотель бы менять через бд

Взять параметры с БД и на их основании сгенерить crontab.