Because different distributions handle this task differently, we will examine how Fedora (and friends) handle the task and how Ubuntu (and friends) handle the task. As well we will also examine a neutral method that can always work in a pinch. All three methods will be command line, so stretch out those fingers and get ready to type.

Fedora (and friends)

The Fedora distribution uses the chkconfig command to update and query system run-level information for system services. The usage of this command is:

chkconfig OPTIONS SERVICE ON/OF

Where:

• OPTIONS are the various options the command offers.
• SERVICE is the service you want to add at startup.
• ON/OFF is either on or off – depending on if you want the service to start or not.

The confusion with the chkconfig command generally boils down to runlevel. The typical Linux runlevels are:

• 0 – Halt
• 1 – Single user mode
• 2 – Multi user mode
• 3 – Multi user mode with networking
• 4 – Not used
• 5 – X11
• 6 – Reboot

So with chkconfig you can also define at which point the service starts. So let’s say you want Apache to start at boot and you want it to start for levels 3, 4, and 5. For this you would issue the command (as the root user):

chkconfig –level 345 httpd on

Now, if you don’t want Apache to run at boot you could issue the command:

chkconfig httpd off

If you want to know what services are running at boot you can issue the command:

chkconfig –list

The above command will list out all services that are starting at boot time.

Ubuntu (and friends)

Ubuntu (and friends) takes a totally different route to the same destination. Instead of using chkconfig Ubuntu uses the update-rc.d command. This command makes things pretty simple. The command structure is:

update-rc.d SERVICE OPTIONS

Where OPTIONS are available options and SERVICE is the service you want to start.

With update-rc.d there is an option that makes it simple: defaults. So to add sshd to the start up process, you would issue the command:

sudo update-rc.d sshd defaults

To remove the same service from start up you would issue the following command:

sudo update-rc.d sshd remove

Now let’s take a look at a fail safe, nearly-universal method

rc.local

There is another means of getting a service to start. I recommend using either of the two above before you try this means. The rc.local file is a file that is executed at the end of the multiuser runlevel. By default, this script does nothing, but you can add to it so that it does.

Say you want Apache to start at boot up, and you want to do so from rc.local. You can do this by adding one of the following lines at the end of your /etc/rc.local file.

Fedora:

/etc/init.d/rc.d/httpd start

Ubuntu:

/etc/init.d/apache2 start

Save that file and you should be good to go. If you change your mind and do not want that service to start at boot, just remove the line you added.

Final thoughts

The above should allow you get that service that needs to start at boot working correctly. Make sure, however, you use the distribution-prescribed method before you use the rc.local method.

If you look at the /etc directory you will find directories that are in the form rc#.d (Where # is a number reflects a specific initialization level – from 0 to 6). Within each of these directories is a number of other scripts that control processes. These scripts will either begin with a “K” or an “S”. All “K” scripts are run before “S” scripts. And depending upon where the scripts are located will determine when the scripts initiate. Between the directories the system services work together like a well-oiled machine. But there are times when you need to start or stop a process cleanly and without using the kill or killall commands. That is where the /etc/init.d directory comes in handy.

Now if you are using a distribution like Fedora you might find this directory in /etc/rc.d/init.d. Regardless of location, it serves the same purpose.

In order to control any of the scripts in init.d manually you have to have root (or sudo) access. Each script will be run as a command and the structure of the command will look like:

/etc/init.d/command OPTION

Where command is the actual command to run and OPTION can be one of the following:

• start
• stop
• reload
• restart
• force-reload

Most often you will use either start, stop, or restart. So if you want to stop your network you can issue the command:

/etc/init.d/networking stop

Or if you make a change to your network and need to restart it, you could do so with the following command:

/etc/init.d/networking restart

Some of the more common init scripts in this directory are:

• networking
• samba
• apache2
• ftpd
• sshd
• dovecot
• mysql

Of course there may be more often-used scripts in your directory – it depends upon what you have installed. The above list was taken from a Ubuntu Server 8.10 installation so a standard desktop installation would have a few less networking-type scripts.

But what about /etc/rc.local

There is a third option that I used to use quite a bit. This option is the /etc/rc.local script. This file runs after all other init level scripts have run, so it’s safe to put various commands that you want to have issued upon startup. Many times I will place mounting instructions for things like nfs in this script. This is also a good place to place “troubleshooting” scripts in. For instance, once I had a machine that, for some reason, samba seemed to not want to start. Even afer checking to make sure the Samba daemon was setup to initialize at boot up. So instead of spending all of my time up front with this I simply placed the line:

/etc/init.d/samba start

in the /etc/rc.local script and Samba worked like a charm. Eventually I would come back and trouble shoot this issue.

Final Thoughts

Linux is flexible. Linux is so flexible there is almost, inevitably, numerous ways to solve a single problem. Starting a system service is one such issue. With the help of the /etc/init.d system (as well as /etc/rc.local) you can pretty much rest assured your service will start.