How to Run a Script Automatically at Boot on Linux (systemd)

Updated: 28 September 2026 · Applies to: systemd 252 to 259 on AlmaLinux and Rocky Linux 9 and 10, RHEL 9 and 10, Ubuntu 24.04 and 26.04, Debian 13

To run a script once every time the server starts, for example to set a network option, mount a special disk or send a "server is up" message, use a small systemd service of type oneshot. It runs at the right moment in the boot, logs its output, and reports errors. The old /etc/rc.local file still works as a fallback, as described at the end.

1. Write the script

cat > /usr/local/sbin/boot-tasks.sh <<'EOF'
#!/bin/bash
set -e
echo "Boot tasks started"
# your commands here
EOF
chmod 755 /usr/local/sbin/boot-tasks.sh

Test it by hand once: /usr/local/sbin/boot-tasks.sh.

2. Create the service

Create /etc/systemd/system/boot-tasks.service:

[Unit]
Description=Run boot tasks
After=network-online.target
Wants=network-online.target

[Service]
Type=oneshot
ExecStart=/usr/local/sbin/boot-tasks.sh
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

Leave out the two network lines if the script does not need the network; it then runs earlier. RemainAfterExit=yes keeps the service shown as "active" after the script has finished.

3. Enable it

systemctl daemon-reload
systemctl enable boot-tasks.service
systemctl start boot-tasks.service     # run it now to test
journalctl -u boot-tasks.service

From the next reboot on, it runs automatically. Check after a reboot with systemctl status boot-tasks.service.

Alternative: cron @reboot

For a simple job as a normal user, add a line with crontab -e:

@reboot /home/alice/bin/start-notes.sh

It runs when the cron service starts, without any control over the order of the boot.

Fallback: /etc/rc.local

systemd still runs /etc/rc.local (on AlmaLinux, Rocky Linux and RHEL the file is /etc/rc.d/rc.local) through its compatibility service, but only if the file is executable: chmod +x /etc/rc.d/rc.local. It does not run last in the boot any more, as it did on CentOS 6 and older systems, so a service unit is the more reliable choice.

For long-running programs rather than one-time tasks, see how to add a custom script to systemd as a service.

Official documentation: systemd.service (Type=oneshot) and systemd-rc-local-generator.