Cfrtjryk

The header looks like this:

#!/bin/sh -e

#

# rc.local - executed at the end of each multiuser runlevel

#

# Make sure that the script will "exit 0" on success or any other

# value on error.

What is the reason for this file (it does not contain much), and what commands do you usually put in it? What is a "multiuser runlevel"? (I guess rc is "run commands"?)

A runlevel is a state of the system, indicating whether it is in the process of booting or rebooting or shutting down, or in single-user mode, or running normally. The traditional init program handles these actions by switching to the corresponding runlevel. Under Linux, the runlevels are by convention:

• S while booting,


• 0 while shutting down,


• 6 while rebooting,


• 1 in single-user mode and


• 2 through 5 in normal operation.

Runlevels 2 through 5 are known as multiuser runlevels since they allow multiple users to log in, unlike runlevel 1 which is intended for only the system administrator.

When the runlevel changes, init runs rc scripts (on systems with a traditional init — there are alternatives, such as Upstart and Systemd). These rc scripts typically start and stop system services, and are provided by the distribution.

The script /etc/rc.local is for use by the system administrator. It is traditionally executed after all the normal system services are started, at the end of the process of switching to a multiuser runlevel. You might use it to start a custom service, for example a server that's installed in /usr/local. Most installations don't need /etc/rc.local, it's provided for the minority of cases where it's needed.

rc denotes "run-control",

The multiuser runlevel would be defined as the level at which networking is available and thus connections to the server could be made using those services in lieu of hard-wired console connections.

Mind you, servers are generally managed by a service processor (under various names) which do support network connections and in turn act as if you indeed had a hard-wired console.

As for the rc.local file, this is a convenience to allow you to specify all of the "local" (site-specific) objects (daemons and/or once-at-boot scripts) you want to start. You may choose to use this paradigm or actually populate '/etc/init.d' with start/stop scripts, appropriately.

The rc.local file on Debian is mostly for compatibility with non-init style systems. You should not use it.

Instead, it is recommended that you copy /etc/init.d/Skeleton to a new init script for whatever you want to happen while changing runlevels, then use inserv to enable it.

I mainly use it for two things:

1. to log the date and kernel version of every reboot. a simple one-liner that can easily be added to systems without any stuffing around...and far less prone to the boot history being corrupted than running uptimed.




2. to revive the old /etc/rc.boot/ directory that used to be in debian up until a few years ago. I still have some simple scripts in there that aren't worth the effort of rewriting as an init.d script (e.g. a Q&D script to mail dmesg to root, and another one to use hdaparm to disable idle spindown and blockdev to set read-ahead size), and I'm happy for them to be run after all other boot-time scripts.

e.g.

echo "$(date +%s),$(date),$(uname -a)"  >> /var/log/reboot.log



[ -d /etc/rc.boot ] && run-parts /etc/rc.boot

Also, I wrote /etc/rc.local scripts earlier this year for centos and debian distros to get the ec2-style metadata from openstack (on http://169.254.169.254/) so that VMs would get their IP, hostname, ssh keys, and other instance-specific information. cloud-init has since been ported to these distros, so the scripts are obsolete now.