/etc/init.d directory exactly equivalent (functionally) to what I presume to be the more standard
/etc/rc.d/ (at least on arch)? Is there any particular reason canonical used init.d instead of rc.d for startup scripts?
/etc/init.d to store SysVinit scripts because Ubuntu is based on Debian and that's what Debian uses. Red Hat uses
/etc/rc.d/init.d. I forget what Slackware uses. There just isn't a standard location.
Ubuntu briefly switched from SysVinit to Upstart, but has now turned to using
/etc/init.d was the old historical location for SVR4. I forgot why redhat added the /etc/rc.d/ level. I think to isolate things onto rc.d, but then needed to add a bunch of symlinks anyway for backwards compatibility. So there is /etc/init.d in redhat, just it symlinks elsewhere.
So the standard location is /etc/init.d, though it may be a symlink not a real directory.
There were some really old Linux distros that copied BSD with /etc/rc.local but pretty much no one uses that anymore.
/etc/rc.d directory tree denotes an Init system which follows the 4.4 BSD tradition of system initialization, which is usually called the
rc init system. All the modern (Free/Open/Net)BSD system and Slackware Linux follow this tradition.
/etc/init.d directory tree denotes the System V (SysV) init system which follows the AT&T UNIX, SunOS, Solaris tradition of system initialization. This is commonly called the SysV Init system. Debian proper still follows this tradition in the Wheezy series, but plans to use SystemD in the Jessie series. Historically, RedHat and derivatives have used SysV Init, but don't anymore.
Also, over time, features of both init schemes have been adopted by distributions.
/etc/init.d is a place where you can quickly deploy an init script. The second step towards activating this script is to run a
chkconfig command on it. Say you run
chkconfig --add <yourscript>, symbolic links will be created between
/etc/rc.d/rcX.d/S50<script> for example. X in rcX.d representing the runlevel number of the script, and S50 representing the script type (there are two of these types, S & K, S tells the system to start the script when it boots up, and K tells the system to exit the script gracefully when you shut down. The number after S/K represents the order at which these happen, in case you have some scripts that depend on others being active first). By default, if no runlevel is specified inside the script or when you issue the runlevel command, CentOS6 creates S50 scripts for runlevels 2,3,4,5 and K50 for runlevels 0,1,6 .
here's a high level all encompassing answer (hopefully)
In the context of Unix-like systems, the term rc stands for the phrase "run commands". It is used for any file that contains startup information for a command. It is believed to have originated sometime in 1965 at a runcom facility from the MIT Compatible Time-Sharing System (CTSS).
Runlevels are implemented as directories on the system which contain shell scripts to start and stop specific daemons, e.g. /etc/rc1.d/. Most systems have directories for runlevels 0-6.
To avoid script duplication the files in the rc#.d/ directories are actually symbolic links to script files located in the /etc/init.d/ directory.
Custom scripts to carry out tasks on the system can be created in the /etc/init.d/ directory and then symbolic links to those scripts can be created in the /etc/rc#.d/ directories to start or stop the scripts as necessary. For some tasks, however, creating full-blown System V-style init scripts, complete with start and stop options, is overkill; some tasks, for example, need to be executed once when the system boots up, but never need to be killed, or do not need to be run every time the system changes runlevels, or for other reasons are not totally amenable to execution from a System V Init script.
- In simplest terms the directory framework actually containing everything is
- As what pointed out in CentOS 6, which is also true to now in RHEL 7.8, the folder
/etc/init.dis a link pointing to
- My understanding based on using RHEL, SLES, IRIX, and playing with other distributions is that "linux" refers really only to the linux kernel and it is up to the manufacturer are however you want to call it for who makes a functional distribution of linux that you end up using. And that manufacturer can do things however they like for a myriad of reasons which is why you can and will find subtle differences such as this. The
rcis a framework which is largely followed by everyone giving out a linux distribution, but realize it is a framework and it really comes down to how they write all that code in the run commands to make the operating system start up and shutdown.
- The mention of the old way of
SysVinitand now the current way of
SystemD. These two items are and old way vs the new [modern] way of service and system management in linux that encompasses everything inclusive of start up to shut down. But the code [files] that make this up resides under the
run commandsdirectory framework. And for backwards compatibility basically all new linux distributions running SystemD still support all the old SysVInit way of doing things by simply keeping the existing directory
rcframework and linking [redirecting] the old sysvinit commands to the corresponding systemd ones (I have not seen any yet that do not).
- In the end for your given linux ditro you are using you want to at leas take a quick look under
/etc/init.dto see how that all links up and make logical sense in regards to directory locations. It's not one
versusthe other. They go hand in hand, the primary reason so that only one copy of a run command [script] is located in one place (in RHEL7.8 that is
/etc/rc.d/init.d/where the actual file resides) but as you will see the scripts defined under rc0 thru rc6 which corresponds to what gets called based on runlevel are all links. It's all about managing the mess [of files].