I'm not sure if this design pattern even has one well-known, official name or not, but drop-in configuration files and drop-in configuration directory are terms I've seen used to describe it. If a configuration file syntax has an include directive that can take wildcards, it can be implemented even without modifying the program in question at all.
In a nutshell, it enables automated administration by allowing software packages and/or automation tools to drop in individual configuration snippets as needed instead of trying to programmatically modify one single configuration file. It can also benefit human system administrators by allowing settings to be grouped by purpose.
Note that /etc/init.d
does not exactly follow this pattern, but a well-known, somewhat more complex pattern known as SysVinit startup/shutdown scripts: the scripts in /etc/init.d
are not simply all incorporated to the start-up process, but there are separate directories of symbolic links (/etc/rc.d/rc[0-6].d/
) that are used to determine which scripts will be called and in which order. Some more modern implementations generate and manage the symlinks in these directories automatically based on specially-formatted comments at the beginning of the scripts in /etc/init.d/
... but this is a later extension, not an original part of the SysVinit startup/shutdown script pattern.
/etc/init.d
are not configuration files. They are scripts. They do not form a configuration structure. You have picked an example that is not an example of what you want to know. And the ways that collections of scripts are processed are not the same as the ways in which configuration files are amalgamated. This is not a single pattern.