How to start program at Linux boot automatically

Starting important programs automatically during Linux boot keeps services, monitoring agents, and supporting tools available without manual intervention. Consistent autostart behaviour is especially useful on servers, appliances, and remote systems that may reboot without an administrator present, reducing the risk of forgotten processes after maintenance or power events.

In modern environments, the init system systemd orchestrates background services through unit files, while graphical desktops such as GNOME and KDE use their own session managers to start user applications. Additional mechanisms such as the cron daemon, the legacy /etc/rc.local script, and shell initialisation files help schedule one‑shot tasks, boot‑time configuration, or commands tied to interactive logins.

The appropriate mechanism depends on whether a program should run as a long‑lived daemon, a one‑time boot task, or a per‑session application. Misusing login shells or legacy hooks for background services can make troubleshooting harder, and some distributions may disable or omit compatibility layers such as /etc/rc.local. Common options described here cover most scenarios, while distribution documentation remains the final reference for edge cases.

Modern Linux distributions primarily use systemd to manage services during boot. systemd handles various system processes and can be configured to autostart programs using service unit files. This method is recommended for most users because of its flexibility and widespread support.

To use systemd, the program that should start at boot needs an associated service unit file. If it does not, a custom one can be created under /etc/systemd/system or a similar directory. The steps below show how to enable an existing program to start automatically using systemd.

1. Check if the service unit for the program exists (optional).

   $ sudo systemctl list-unit-files --type=service
   [sudo] password for user:
   UNIT FILE                              STATE
   accounts-daemon.service                enabled
   apparmor.service                       enabled
   apport-autoreport.service              static
   apport-forward@.service                static
   apport.service                         generated
   apt-daily-upgrade.service              static
   apt-daily.service                      static
   atd.service                            enabled
   autovt@.service                        enabled
   blk-availability.service               enabled
   bootlogd.service                       masked
   bootlogs.service                       masked
   bootmisc.service                       masked
   checkfs.service                        masked
   checkroot-bootclean.service            masked
   checkroot.service                      masked
   cloud-config.service                   enabled
   cloud-final.service                    enabled
   cloud-init-local.service               enabled
   cloud-init.service                     enabled
   console-getty.service                  disabled
   ##### snipped #####

   A custom service unit is required for in‑house programs or software that does not ship one with the package.
   Related: Creating and modifying systemd unit files

2. Check if the service unit is enabled (optional).

   $ sudo systemctl is-enabled mysql
   disabled

   A unit in the enabled state is started automatically during boot according to its target.

3. Enable the service unit to execute during startup.

   $ sudo systemctl enable mysql
   Synchronizing state of mysql.service with SysV service script with /lib/systemd/systemd-sysv-install.
   Executing: /lib/systemd/systemd-sysv-install enable mysql
   Created symlink /etc/systemd/system/multi-user.target.wants/mysql.service → /lib/systemd/system/mysql.service.

4. Confirm that the service unit is enabled (optional).

   $ sudo systemctl is-enabled mysql
   enabled

   Use systemctl status <unit> to inspect runtime state once the system has booted.

The cron daemon schedules recurring or one‑off tasks in Linux. It can start programs at specific times, including during system startup, using per‑user or system‑wide configuration. cron jobs are well suited to lightweight scripts or commands that do not need full service management from systemd.

Using cron to autostart a program involves adding an entry to the user’s crontab file. This method is helpful for running a command as a particular user immediately after boot without creating a dedicated systemd unit.

1. Open the crontab editor.

   $ crontab -e

   The first invocation prompts for an editor selection, and a new crontab is created for the calling user.

   $ crontab -e
   no crontab for user - using an empty one
   
   Select an editor.  To change later, run 'select-editor'.
     1. /bin/nano        <---- easiest
     2. /usr/bin/vim.basic
     3. /bin/ed
   
   Choose 1-3 [1]:

   The resulting crontab runs with the privileges of the user who created it; to run as root, invoke crontab -e as the root account.

2. Insert a line starting with @reboot.

   # m h  dom mon dow   command
   @reboot

   The @reboot keyword marks jobs that run once at boot, after the cron daemon has started.

3. Add the command to start the program after @reboot.

   @reboot /sbin/ip addr | grep inet\ | tail -n1 | awk '{ print $2 }' > /etc/issue && echo "" >> /etc/issue

   Use full paths to binaries and keep the command on a single line to avoid parsing issues.

4. Save the crontab file.

   $ crontab -e
   crontab: installing new crontab
   $ 

   Per‑user crontab files are stored under /var/spool/cron or /var/spool/cron/crontabs depending on the distribution.

5. Verify proper crontab configuration (optional).

   $ crontab -l
   # m h  dom mon dow   command
   @reboot /sbin/ip addr | grep inet\ | tail -n1 | awk '{ print $2 }' > /etc/issue && echo "" >> /etc/issue

rc.local is a legacy script traditionally used to execute commands during system startup. Although it is not enabled by default on all modern systemd‑based systems, many installations retain compatibility to ease migration from older init systems. The script executes near the end of the boot sequence.

Because /etc/rc.local runs with root privileges, any commands placed in it can modify system state without further authentication. Only trusted commands and scripts should be added, and changes should be kept small and auditable.

1. As the root user, open or create the /etc/rc.local file using a preferred editor if it does not exist.

   $ sudo vi /etc/rc.local

2. Add placeholder code to the file.

   #!/bin/bash
   
   exit 0

   The script should start with a valid interpreter such as /bin/bash and terminate with an exit status, where 0 indicates success.

3. Insert commands and logic as needed.

   #!/bin/bash
   
   /sbin/ip addr | grep inet\ | tail -n1 | awk '{ print $2 }' > /etc/issue
   echo "" >> /etc/issue
   
   exit 0

4. Set the file to executable.

   $ sudo chmod a+x /etc/rc.local

   When enabled by the distribution, /etc/rc.local is executed once as root near the end of the boot process.

GNOME is a popular desktop environment for Linux, used by distributions such as Ubuntu and Red Hat Enterprise Linux. Autostarting programs in GNOME relies on the desktop session manager, which loads per‑user configuration at login and launches graphical applications in the user context.

Using the dedicated startup‑applications mechanism avoids manual edits to low‑level files and keeps user applications separate from system services. This approach is convenient for mail clients, chat applications, and other desktop tools that should appear automatically after login without affecting system boot.

KDE is another widely used desktop environment in Linux, known for extensive customisation options. Its session manager offers built‑in controls for managing startup applications, including both scripts and graphical programs.

Configuring autostart within KDE System Settings keeps user applications logically grouped with the desktop profile. This arrangement is suitable for tools that should start whenever a user logs in to a KDE session without running as system‑wide daemons.

When a terminal emulator or virtual console is opened, a new shell process is created. On most Linux distributions, Bash acts as the default shell and reads a sequence of startup files in order:

  /etc/profile
  ~/.bash_profile
  ~/.bash_login
  ~/.profile

These files contain Bash commands that configure environment variables, aliases, and other session‑specific settings. Many systems also source additional files such as /etc/bash.bashrc and ~/.bashrc from these initial scripts, providing convenient hooks for per‑user customisation.

A program that should run on every interactive Bash session can be invoked from one of these files, typically ~/.bashrc or ~/.profile, depending on distribution defaults and whether the session is login or non‑login.

PS1='${debian_chroot:+($debian_chroot)}$begin:math:display$\\033\[01\;32m$end:math:display$\u@\h$begin:math:display$\\033\[00m$end:math:display$:$begin:math:display$\\033\[01\;34m$end:math:display$\w$begin:math:display$\\033\[00m$end:math:display$ \$ '
 
PATH=/home/user/bin:$PATH
 
export EDITOR=/usr/bin/vim
 
alias ll="ls -l"

1. Open the per‑user ~/.bashrc file in a text editor.

   $ vi ~/.bashrc

2. Append a command near the end of the file to start the required program for each interactive shell.

   my_program &

   Launching long‑running daemons or GUI applications from ~/.bashrc affects every interactive terminal and can make failures harder to diagnose.

3. Reload the configuration in the current shell to test the change.

   $ . ~/.bashrc

   The dot command executes ~/.bashrc in the current shell so that new settings and commands take effect immediately.

4. Open a new terminal session and confirm that the program starts automatically.

   For login shells that do not source ~/.bashrc directly, the distribution may chain login files to include it.