Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I wanted to partition a single cron file into separate logical units and place them in subdirectories. One folder under cron.d would have all crons associated with say, removing certain types of directories. Another sub directory would contain a cron that would handle checking the size of certain directories etc.

Is it possible to have sub dirs under cron.d? For example:



share|improve this question

No. At least this is the case on Debian, which uses Vixie cron. cron(8) has this to say about the cron.d directory:

The intended purpose of this feature is to allow packages that require finer control of their scheduling than the /etc/cron.{daily,weekly,monthly} directories to add a crontab file to /etc/cron.d. Such files should be named after the package that supplies them. Files must conform to the same naming convention as used by run-parts(8): they must consist solely of upper- and lower-case letters, digits, underscores, and hyphens.

This pretty clearly does not support recursing into sub-directories. Other cron daemons might support that, I suppose.

If using a cron daemon that doesn't support that, as one probably is doing on most Linux systems I would guess, I think your best option may be a simple script that takes a tree of config files in, say, /usr/local/etc/local-crons/ and concatenates them together into single files in /etc/cron.d.

For example, let's say you had the following files:

  • /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

Your script then processes the directory tree /usr/local/etc/local-crons/ and creates the following files:

  • /etc/cron.d/local-crons-monitoring
  • /etc/cron.d/local-crons-removals

local-crons-monitoring would contain the contents of foo.cron and bar.cron; local-crons-removals would contain the contents of baz.cron and quux.cron.

If you wanted to get fancy, your script could quite easily check the last modification time of the .cron files and compare it to the last modification time of the relevant file in /etc/cron.d/ in order to see if it has any work to do. So then this too could be cronned.

I think that is probably how I would do it anyway.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.