Нет. По крайней мере, так обстоит дело с Debian, который использует Vixie cron. cron(8)
может сказать следующее о каталоге cron.d:
Предполагаемая цель этой функции - позволить пакетам, которые требуют более точного управления своим расписанием, чем каталоги /etc/cron. averagedaily,weekly,monthly}, добавить файл crontab в /etc/cron.d. Такие файлы должны быть названы в честь пакета, который их поставляет. Файлы должны соответствовать тем же правилам именования, которые используются run-parts(8): они должны состоять только из прописных и строчных букв, цифр, подчеркиваний и дефисов.
Это довольно явно не поддерживает возврат в подкаталоги. Я полагаю, что другие демоны cron могут это поддержать.
Если бы я использовал демон cron, который не поддерживает это, как, вероятно, можно сделать на большинстве систем Linux, я думаю, что лучшим вариантом может быть простой скрипт, который принимает дерево файлов конфигурации, скажем, в /usr/local/etc/local-crons/
и объединяет их в отдельные файлы в /etc/cron.d
.
Например, допустим, у вас были следующие файлы:
/usr/local/etc/local-crons/monitoring/foo.cron
/usr/local/etc/local-crons/monitoring/bar.cron
/usr/local/etc/local-crons/removals/baz.cron
/usr/local/etc/local-crons/removals/quux.cron
Затем ваш скрипт обрабатывает дерево каталогов /usr/local/etc/local-crons/
и создает следующие файлы:
/etc/cron.d/local-crons-monitoring
/etc/cron.d/local-crons-removals
local-crons-monitoring
будет содержать содержимое foo.cron
и bar.cron
; local-crons-removals
будет содержать содержимое baz.cron
и quux.cron
.
Если вы хотите получить фантазию, ваш скрипт может легко проверить время последнего изменения файлов .cron
и сравнить его с временем последнего изменения соответствующего файла в /etc/cron.d/
, чтобы увидеть, есть ли у него какой-либо работа, которую нужно сделать. Так что это тоже может быть короновано.
Я думаю, что, вероятно, я бы так и сделал.