Нет. По крайней мере, так обстоит дело с 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/ , чтобы увидеть, есть ли у него какой-либо работа, которую нужно сделать. Так что это тоже может быть короновано.
Я думаю, что, вероятно, я бы так и сделал.