97

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"?)

Gilles 'SO- stop being evil'
  • 829,060
Emanuel Berg
  • 6,903
  • 8
  • 44
  • 65
  • 2
    I don't know if this is the "official" purpose of the file, but I found out that I can use the file for what should happen on startup, and would require super user access, but without having to provide the password. That would typically involve colors, the keyboard, and other such stuff. Check out some examples here. – Emanuel Berg Aug 07 '13 at 03:10

4 Answers4

88

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.

Pablo A
  • 2,712
Gilles 'SO- stop being evil'
  • 829,060
  • 2
    I found out today that on current FreeBSD, rc.local may get executed pretty early. Definitely not after all normal system services are started. I wanted a beep when sshd access to a headless machine would become available, and rc.local wasn't suitable for this reason. Since the original question is about Debian, this comment is probably irrelevant for the OP. – MvG Mar 05 '16 at 00:06
  • 1
    @MvG Thanks for the information. rc.local was traditionally run last, but I see that FreeBSD stopped doing that when they switched to a dependency-based system. Mind you, even if rc.local was invoked after /etc/rc.d/sshd, that wouldn't work perfectly: rc.local would be invoked soon after the sshd process was started, it could be invoked before sshd had started to listen to the network (but we'd be talking tenths of a second at most in a typical setup). – Gilles 'SO- stop being evil' Mar 05 '16 at 00:42
  • I'm trying to use it to set up network for lxc containers and auto start them. But it stops after iptables-apply /root/iptables. I'm in the process of figuring out what's wrong (waiting for next reboot). But if you've got any suggestions, I'm all ears. – x-yuri May 18 '16 at 16:28
  • 1
    @x-yuri This requires way more information than what you posted here. I don't even know what “it” is in “it stops”. Ask a new question that explains what you did. – Gilles 'SO- stop being evil' May 18 '16 at 16:45
17

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.

JRFerguson
  • 14,740
  • 1
    Okay, but why is the file there, and when do you typically use it, and how (for example, what commands make sense to put in it)? – Emanuel Berg Oct 01 '12 at 22:59
6

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.

Update: As per the comment below, this answer is no longer recommended. However, this answer was posted several years before skeleton deprecation, and that skeleton still exists in Debian unstable as of January 2019.

bahamat
  • 39,666
  • 4
  • 75
  • 104
4

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.

cas
  • 78,579