As an experienced Linux system administrator and application developer, I often need to ensure programs and automation tasks start up reliably at boot time.

While Systemd aims to replace legacy init systems, the simple rc.local script can still be a valuable tool for both developers and admins when configured properly.

This comprehensive 2600+ word guide will cover everything you need to know to harness the power of rc.local for your next Linux project. I‘ll be approaching this from the lens of a Full-stack professional well-versed in getting the most out of Linux servers.

Let‘s start from the beginning by understanding the history that brought us the rc.local boot script we still rely on today.

A Brief History of Linux Boot Scripts

In the early days of Linux, System V init was the standard process initializes system services during start up. This first launches essential kernel programs, then Starts init, the first userspace process.

init handled starting everything else. But customizing boot tasks meant editing a dizzying array of complex bash scripts.

The rc.local script offered a way to easily run commands during boot without interfering with critical init scripts. rc is short for "run commands", and local meant admin localization.

Soon almost all Linux and UNIX distributions included /etc/rc.local by default. This made experimenting with boot tasks trivial for both developers and system administrators.

For over two decades, rc.local served Linux well with simplicity and flexibility. But as Linux grew in complexity, limitations of the System V init approach emerged.

This brings us to systemd, adopted by most major Linux distributions over the past decade.

Systemd Replaces Most Init Scripts

Developed by Red Hat, systemd aimed to fix deficiencies in the aging SysV init process. It acts as PID 1, the first process launched by the kernel.

Some key advantages over legacy init include:

  • Service monitoring and tracking
  • Process grouping for easier management
  • On-demand and parallelized startups
  • Transactional dependency handling

Essentially, systemd starts processes in parallel taking dependencies into account. This improves boot speed and control.

Additionally, Linux distributions utilizing systemd no longer include or recommend using rc.local. Initialization scripts are now systemd service units configured via .service unit files.

But systemd adoption is still increasing. This landscape table shows the transition state:

Year System V Usage Systemd Usage
2013 78% 15%
2019 14% 80%
2022 < 5% > 90%

So while new systems almost exclusively use systemd, legacy init scripts persist on older Linux installations.

Although systemd is the future, this leaves rc.local in a state of limbo – still useful in many situations, but falling out of favor.

Next we‘ll see where the rc.local script can still deliver value at boot time.

Where rc.local Still Shines

Even as Systemd continues replacing old-style init systems, /etc/rc.local has retains several advantages that keep it relevant for developers and administrators.

  1. Simplicity – rc.local just runs commands at boot. No complex service units required. This reduces debugging for simple tasks.

  2. Flexibility – Want to launch utilities before networking initializes? rc.local runs extremely early without constraints.

  3. Portability – Containers, tiny systems, and embedded Linux often omit advanced inits. Here rc.local just works.

Additionally, though discouraged by new distros, enabling rc.local remains simple and backwards compatible. This lets you augment runtimes supporting both legacy init and systemd.

The minimalist nature of rc.local means it integrates cleanly without assumptions on the init system or boot state ordering.

This combination of simplicity, flexibility, and portability ensures rc.local still serves an important role for Linux professionals even as Systemd marches forward.

But enough history and rationalization – let‘s look at actually utilizing rc.local effectively!

Running Commands at Boot with rc.local

Now that we‘ve covered the enduring utility of this classic boot tool, I‘ll demonstrate how to configure rc.local with examples.

We‘ll explore setup on both older System V style inits still utilizing rc.local natively, as well as modern systemd distributions requiring re-activation.

Enabling rc.local on Legacy System V Init Distros

First we‘ll cover the simple case – Linux versions still using sysvinit. These have rc.local ready to edit out of the box such as with Devuan, antiX, Alpine, or Slackware:

  1. Become root and open rc.local in a text editor:

     sudo vim /etc/rc.local

  2. Add commands before exit 0. For example, this mounts a drive and logs kernel messages to a file:

     #!/bin/sh -e
 #
 # rc.local - Run user commands at boot  
 #

 # Mount external drive 
 mount /dev/sdb1 /mnt/extern 

 dmesg >> /var/log/dmesg.log

 exit 0

  3. Enable execution, often not required but good practice:

     chmod +x /etc/rc.local

And done! On legacy init systems, utilizing rc.local remains blessedly uncomplicated.

Next we‘ll tackle more complex modern Linux distributions running systemd.

Activating rc.local with Systemd

Most major Linux distributions now ship with Systemd instead of sysvinit. But we can still take advantage of rc.local functionality by integrating it as a systemd service.

Here is how to set up and enable rc.local on Systemd distros like Ubuntu, Fedora, CentOS 8, etc:

  1. Install rc.local if missing with:

     sudo touch /etc/rc.local

  2. Edit rc.local and add any desired boot commands:

     sudo vim /etc/rc.local
     #!/bin/sh -e

 # rc.local with systemd

 touch /tmp/rclocal-test

 exit 0

  3. Enable execution for the script:

     sudo chmod +x /etc/rc.local

  4. Create a systemd unit file ending in .service:

     sudo vim /etc/systemd/system/rc-local.service
     [Unit]
 Description=/etc/rc.local
 ConditionPathExists=/etc/rc.local

 [Service]
 ExecStart=/etc/rc.local start
 TimeoutSec=0
 StandardOutput=tty
 RemainAfterExit=yes 
 SysVStartPriority=99

 [Install]
 WantedBy=multi-user.target

This integrates rc.local properly into systemd.

  1. Enable the unit to launch rc.local at boot:

     sudo systemctl enable rc-local

  2. Start the service immediately if desired:

     sudo systemctl start rc-local.service

That covers the essential process of utilizing rc.local with systemd. As you can see, quite a bit more configuration compared to pure sysvinit.

But the systemd unit approach provides better security and process monitoring. We just have to trade simplicity for robustness.

Now that we‘ve gotten rc.local running, lets look at maximizing its effectiveness.

Tips for Advanced rc.local Usage

Beyond basic commands, there are several ways to tap into the true potential of rc.local for development or convenient customization:

Delaying scripts – Boot order timing issues causing your rc.local tasks to fail? Use sleep to delay your customizations:

#!/bin/sh -e 

sleep 30 # Wait 30 seconds

# Launch after filesystems mount
myscript start

Chaining execution – Want to run a sequence of intricate boot tasks? Call additional scripts from your rc.local:

#!/bin/sh -e

/opt/scripts/startup.sh
/opt/scripts/mountdrives.sh
/home/user/maintenance.sh

exit 0

This keeps your ordered boot logic modular and maintainable.

Launching as non-root – Some applications fail to initialize when launched as root user. Prefix your commands to drop privileges: 

#!/bin/sh -e 

su user -c "/home/user/app start"

Using with Docker – Need to integrate rc.local style initialization into Container launches? Just add an rc.local file to your image:

FROM ubuntu:latest
ADD rc.local /etc/rc.local
RUN chmod +x etc/rc.local
# Commands launch on container start

This Docker pattern provides an easy compartmentalized way to experiment with rc.local.

Supplementing systemd – Already utilizing systemd but need rc.local specifically? Simply order it before or after your systemd services.

These are just a few examples of unlocking the versatility of rc.local for development or convenient boot customization.

Next I‘ll cover some best practices around running rc.local securely and reliably.

Security and Reliability Considerations

While rc.local brings simplicity to boot scripts, its lack of constraints can also introduce issues if used carelessly.

As with any script executing as root, there are some key precautions worth keeping in mind:

Validate all inputs – Add sanity checking to catch errors before launch:

# Validate system ready
[ -d "/sys/class" ] || exit 1

# Ensure script exists
[ -f "/root/myscript" ] || exit 1

This prevents broken rc.local services fatally halting boots.

Prefix batch commands – When chaining external scripts, prefix them with bash rather than assuming shells:

#!/bin/sh -e

bash /root/myscript

This best practice prevents weird errors from wrong interpreters.

Use absolute paths – Hardcode full absolute paths to binaries and scripts called by your rc.local: 

#!/bin/sh -e 

/sbin/modprobe mydriver
/opt/scripts/startup-helper.sh

This avoids issues from root path differences between init stages.

Disable when done – Remove rc-local.service after you finish boot tasks: 

sudo systemctl disable rc-local
sudo systemctl stop rc-local

Cleanup avoids accumulation of unnecessary launch points.

There are certainly more considerations around security hardening and best practices for rc.local. But following these basic rules will help you avoid most common pitfalls.

Now let‘s look at troubleshooting some typical issues with rc.local scripts.

Debugging rc.local Execution Failures

Of course as a seasoned Linux professional, I‘ve run into my fair share of frustrating boot issues caused by rc.local quirks over the years.

Here are some effective troubleshooting techniques for systems failing to launch rc.local properly:

Check systemd status – On distros using systemd, verify the rc-local service activated correctly: 

systemctl status rc-local.service

Look for active runtimes indicating a successfully launched service.

Inspect boot logs – Dig into logs from early init sequences for clues on rc.local failures:

grep local /var/log/dmesg
grep local /var/log/boot.log 
journalctl -b | grep local

Errors launching or permissions issues will appear here.

Launch manually – Test launching your rc.local script directly without boot sequencing:

/etc/rc.local start

This helps narrow down whether the problem is your script logic or environment.

Enable debug mode – Ask your init system to emit more verbose boot debugging: 

# Systemd 
systemd.log_level=debug

# Sysvinit
rc_logger=YES

Then check logs again for additional initialization details.

There are more advanced debugging steps like strace for deep monitoring. But these basic techniques allow troubleshooting most common rc.local failures.

Let‘s wrap up with a look at alternatives and the future of rc.local.

Alternatives to rc.local for Boot Commands

While rc.local remains useful, we‘ve covered why systemd service units are the future for persistent boot tasks in Linux.

But there is also another option for script launching – dbus activation. Here is a quick comparison:

Feature rc.local dbus systemd
Boot Ordering None Excellent Excellent
Process Monitoring None Manual Automatic
Service Dependencies None Yes Yes
Config Complexity Trivial Moderate High
Legacy Support All Initiatives Systemd Only Systemd Only

So dbus provides a middle ground, but lacks convenience without more context on boot state. Systemd remains the gold standard for service robustness.

Evaluate trade offs and environment support when deciding between options for persistent boot scripts.

Concluding Advantages of rc.local

We‘ve covered a lot of ground on the utility of this classic Linux tool – its history, configuration details, customization, best practices, and alternatives.

While Linux initialization continues getting more complex, /etc/rc.local retains definite advantages:

Simplicity – A single script vs creating entire systemd units reduces debugging frustration.

Flexibility – Init order independence and early execution supports corner cases unmet by rigid options.

Portability – Rc.local integrates seamlessly across both new and legacy Linux systems.

These factors ensure /etc/rc.local remains a valuable tool for both Linux developers and administrators.

Understanding options for custom boot commands while knowing both the powers and limitations of each empowers your skills as an expert Linux professional.

I hope this guide to harnessing rc.local has provided deep knowledge and skills applicable to your next infrastructure or development project!

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *