Ttyjfyk

Excerpt from a Debian mailing list (emphasis added):

When distribution packaging became more and more common, it became clear
that we needed better ways of forming such configuration files out of
multiple fragments, often provided by multiple independent packages. Each
package that needs to configure some shared service should be able to
manage only its configuration without having to edit a shared
configuration file used by other packages.

The most common convention adopted was to permit including a directory
full of configuration files, where anything dropped into that directory
would become active and part of that configuration. As that convention
became more widespread, that directory was usually named after the
configuration file that it was replacing or augmenting. But since one
cannot have a directory and a file with the same name, some method was
required to distinguish, so .d was appended to the end of the
configuration file name. Hence, a configuration file /etc/Muttrc was
augmented by fragments in /etc/Muttrc.d, /etc/bash_completion was
augmented with /etc/bash_completion.d/*, and so forth. Sometimes slight
variations on that convention are used, such as /etc/xinetd.d to
supplement /etc/xinetd.conf, or /etc/apache2/conf.d to supplement
/etc/apache2/apache2.conf. But it's the same basic idea.

Generally when you see that *.d convention, it means "this is a directory
holding a bunch of configuration fragments which will be merged together
into configuration for some service."

For part 2, the reason for the ".d", my best guess would be "distributed", as in not part of the main configuration file, but still part of the configuration.

If you speak about ".d" at the end of directory names, this answer is right, it's just a marker for "directory".

Just don't confuse it with "d" at the and of a file name, like "syslogd", which stands for daemon. A computer process running in the background.

the parent process of a daemon is often (but not always) the init process (PID=1). Processes usually become daemons by forking a child process and then having their parent process immediately exit, thus causing init to adopt the child process. This is a somewhat simplified view of the process as other operations are generally performed, such as dissociating the daemon process from any controlling tty. Convenience routines such as daemon(3) exist in some UNIX systems for that purpose.

It doesn't mean directory per se, basically what is happening is that directories that end in .d (note these are usually only ever in /etc), take configuration parts.

This is designed so distros can include universal defaults in for instance /etc/yum.conf, but then there is a easy to use method for users or other packages to append their own yum configurations in a safe way that won't be overwritten.

As an example for yum...

If I wanted to start using EPEL on my RHEL5 or CentOS Box, I can configure a new repository in the /etc/yum.repos.d folder, (say /etc/yum.repos.d/epel.repo) or install the epel-release package that creates the file automatically, without modifying my default configuration or causing file conflicts that don't need to happen.

What will happen, is most programs will read their default configuration (/etc/yum.conf for instance) and then iterate over their .d folders including configuration snippets into the running program.

Hope it explains it for you.

Just like files can have .ext to specify which type of file it is (commonly called the "extension"), directories sometimes have .d to show it's a directory and not a file. That's its type. The default ls output doesn't visually differentiate directories and files, so the .d is just an old convention to show its type (directory) in such listings.

More generally, the .d directories (/etc/httpd/conf.d, /etc/rc.d, /etc/being another example), indicates that the files contained will be read and used, often for configuration, if they match a given pattern and do not require being explicitly added to some master list.

So if you add files of the form *.repo to /etc/yum.repos.d, yum will use it when running without needing to add it to a list of configurations /etc/yum.conf. If you add files of the form *.conf to /etc/http/conf.d, they will be read by Apache without needing to be explicitly added to /etc/httpd/conf/httpd.conf. Similarly, chkconfig to files in /etc/init.d, cron jobs in /etc/cron.d.

I think, but cannot document, that the .d indicates that the directory is associated with a daemon.

Evidence would indicate that this is at least plausible:

sudo find / -maxdepth 3 -name "*.d"

^{_{Somewhere in the deep recesses of the little bits of ancient Unix history still rattling around in the back of my mind behind the cobwebs, this calls out to me as the correct answer. I believe it may have come from a time when the first mammals roamed the earth before the dinosaurs began to die out and man pages were not only kept on the system but also physically in racks measured by the foot.}}