Is ubuntu's /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?

  • 1
    actually arch linux is the only distro that uses /etc/rc.d that I've seen... I suspect it might be used in bsd. Commented Oct 26, 2010 at 22:24
  • 1
    it is used in freebsd
    – wlraider70
    Commented Feb 4, 2015 at 0:09

8 Answers 8


Ubuntu uses /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 systemd.

  • 2
    Sorry, but /etc/init.d is the standard, as part of the SVR4 standard that Linux start scripts copied. Commented Oct 26, 2010 at 23:17
  • Upstart's website claims Ubuntu has been using it since version 6.10
    – badp
    Commented Jan 16, 2011 at 13:05
  • @badp: Though 6.10, still used SysV-style init scripts in /etc/init.d. The transition to /etc/init/*.conf started later (8.04 was still all SysV-style, 10.04 was already transitioning). Commented Jan 16, 2011 at 13:33
  • 3
    Ubuntu switched from Upstart to systemd since 15.04.
    – Peter
    Commented Jul 21, 2016 at 21:53

/etc/init.d was the old historical location for SVR4.  I forgot why Red Hat 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 Red Hat, 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.


Slackware still uses /etc/rc.d

FreeBSD uses /etc/rc.d and /usr/local/etc/rc.d


Historically, the /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.

The /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.

  • And then there is AIX with "/etc/rc.d/init.d/". A little bit of column A and a little bit of column B.
    – user14755
    Commented Sep 14, 2016 at 23:14

Actually, at least in CentOS 6.8 Santiago, /etc/init.d is just a softlink to /etc/rc.d.

  • That's exactly what I meant, haha. Sorry about the wrong spelling, I edited my reply now. Commented Sep 14, 2016 at 22:19
  • Why do people downvote without giving an explanation? The statement unless intentionally irrelevant can still have value or meaning to some novice reader. Explain when you downvote. I +1 to undo the effect of -1
    – Asad Iqbal
    Commented Jul 14, 2017 at 13:26

Ok so, /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/init.d/<yourscript> and /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)

from wikipedia

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).

summarized from https://www.thegeekdiary.com/understanding-the-rc-scripts-in-linux/

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 /etc/rc.
  • As what pointed out in CentOS 6, which is also true to now in RHEL 7.8, the folder /etc/init.d is a link pointing to /etc/rc.d/init.d
  • 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 rc is 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 SysVinit and 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 commands directory 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 rc framework 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/rc#.d and /etc/rc.d/ and /etc/init.d to see how that all links up and make logical sense in regards to directory locations. It's not one versus the 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].

Puppy Linux has both /etc/rc.d and /etc/init.d, neither being a symlink.  What is a symlink is /etc/rc.d/init.d, which links up a level to /etc/init.d.  (I'm looking at a Slackware-based Puppy – there are also Ubuntu-based and other flavors.)  There's a README.txt in each, explaining their approach.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .