In linux, why are folders for configuration files always named *.d

In linux, why are folders for configuration files always named *.d?

Say

• /etc/init.d
• /etc/grub.d
• /etc/apparmor.d

Solution 1:

The .d stands for directory. It is a convention to distinguish the directory-based configuration from a configuration based on a single configuration file. Often you will have both in some capacity, for example /etc/logrotate.conf and /etc/logrotate.d/.

It is also usually the case that all (reasonably-named) files in such a directory are automatically combined into a single configuration. Packages can then install files into a directory like that, and they will be used automatically. Again, /etc/logrotate.d/ is a good example. By constrast, a directory of configuration files that does not end in .d probably just contains random collation of configuration files belonging to the same package, and you cannot infer anything about how they are processed, example /etc/zsh/.

Solution 2:

To expand a bit on Peter's answer, this .d pattern allows for simpler addition and removal of configuration files: for a given .d program, the admin has the ability to simply copy or remove a file into the .d directory without having to edit an existing config file.

For instance, if you wanted to add a cron job to your system, you could edit /etc/crontab with your new scheduled job using your favorite text editor. This is fine for a single server or handful of servers, but try doing that on 100 servers if you work in a datacenter/cloud environment. In the latter case, you could use something like sed with a temp file or a tool like ex to write the file in place, but there's a bit of risk here if you haven't crafted your command properly. Indeed, I've seen config files completely nuked due to a typo in these edit commands.

Now compare that to placing a file with your scheduled jobs into /etc/cron.d. You just copy the file into it, and the next time cron runs (typically every minute), it'll see the new file and will source/process it accordingly. This is great as Peter states if you like to roll your own packages: the /etc/cron.d file is just another file in the package archive that gets installed. On removal of the package, the cron.d file is removed and your cron no longer runs.

Finally, every program that has a .d directory may have their own implementation as far as how the files are sourced, such as include order and configuration overriding. So whenever you decide to place a file in a .d directory, always verify that it does what you want and don't just assume it works like it does for another program that has a .d directory.