Nie. Tak przynajmniej jest w przypadku Debiana, który używa Vixie cron. cron(8)
ma to do powiedzenia na temat katalogu cron.d:
The
zamierzonym celem tej funkcji jest zezwolenie na pakiety, które
wymagają dokładniejszej kontroli ich harmonogramowania niż
/etc/cron.{daily,weekly,monthly} katalogi, aby dodać plik crontab
do /etc/cron.d. Takie pliki powinny mieć nazwę po pakiecie, który
dostarcza je. Pliki muszą być zgodne z tą samą konwencją nazewnictwa
używane przez części biegowe (8): muszą składać się wyłącznie z części górnej i
małe litery, cyfry, podkreślniki i myślniki.
To dość wyraźnie nie obsługuje rekursji w podkatalogach. Sądzę, że inne demony crona mogą to wspierać.
Jeśli użyjesz demona crona, który nie obsługuje tego, jak prawdopodobnie robisz w większości systemów Linux, zgaduję, myślę, że twoją najlepszą opcją może być prosty skrypt, który pobiera drzewo plików konfiguracyjnych, powiedzmy, /usr/local/etc/local-crons/
i łączy je w pojedyncze pliki /etc/cron.d
.
Załóżmy na przykład, że masz następujące pliki:
/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
Twój skrypt następnie przetwarza drzewo katalogów /usr/local/etc/local-crons/
i tworzy następujące pliki:
/etc/cron.d/local-crons-monitoring
/etc/cron.d/local-crons-removals
local-crons-monitoring
zawierałby zawartość foo.cron
i bar.cron
; local-crons-removals
zawierałby zawartość baz.cron
i quux.cron
.
Jeśli chciałbyś mieć ochotę, twój skrypt może całkiem łatwo sprawdzić czas ostatniej modyfikacji .cron
pliki i porównaj je z czasem ostatniej modyfikacji odpowiedniego pliku w /etc/cron.d/
aby sprawdzić, czy ma jakąkolwiek pracę. Więc to też może zostać zdekonspirowane.
Myślę, że tak pewnie bym to zrobił.