How to automatically run a program on startup in Linux

Running a program automatically during boot keeps background workers, agents, and local support services available before anyone logs in. That matters on servers, kiosks, and always-on workstations where a missed startup task can leave monitoring, synchronization, or application support processes offline.

Most current Linux distributions use systemd to start long-running background programs during boot. A custom service unit under /etc/systemd/system tells the service manager what to launch through ExecStart=, whether the unit should restart on failure, and which boot target should pull it in.

This page covers system startup on a systemd-based Linux host rather than graphical session autostart. The example uses Type=simple for a program that should stay running after boot, while a command that should run once and exit normally should usually use Type=oneshot instead. Creating the script and unit file under /usr/local/bin and /etc/systemd/system requires sudo privileges.

Steps to automatically run a program on Linux startup with systemd:

Create or identify the script or binary that should run during boot.
```
$ sudoedit /usr/local/bin/startup-demo.sh
```
Add the program that should stay running after startup.
```
#!/bin/sh
echo "startup-demo started"
exec sleep infinity
```
Replace the example with the real binary or script that should start automatically. A wrapper script is only needed when the command requires setup before the main process starts.

Make the startup program executable.

$ sudo chmod 755 /usr/local/bin/startup-demo.sh

Create a custom service unit under /etc/systemd/system.
```
$ sudoedit /etc/systemd/system/startup-demo.service
```
Add the unit definition.
```
[Unit]
Description=Startup demo service

[Service]
Type=simple
ExecStart=/usr/local/bin/startup-demo.sh
Restart=on-failure

[Install]
WantedBy=multi-user.target
```
WantedBy=multi-user.target makes systemctl enable link the service into the normal system boot target.

Use Type=oneshot and remove Restart=on-failure when the command should run once at boot and then exit normally.

System services run as root unless the unit sets User=account-name. Add that line when the program should run as a dedicated unprivileged account.
Validate the unit file before loading it.
```
$ sudo systemd-analyze verify /etc/systemd/system/startup-demo.service
```
No output usually means the unit file passed validation.
Reload the service manager so it reads the new unit file.
```
$ sudo systemctl daemon-reload
```
Related: How to manage a Linux service with systemctl
Enable the service for future boots and start it in the current boot.
```
$ sudo systemctl enable --now startup-demo.service
Created symlink /etc/systemd/system/multi-user.target.wants/startup-demo.service -> /etc/systemd/system/startup-demo.service.
```
This command saves the boot-time enablement and starts the service immediately instead of waiting for the next reboot.

Related: How to manage a Linux service with systemctl

Confirm that the unit is enabled at boot.

$ systemctl is-enabled startup-demo.service
enabled

Check the current service state.

$ systemctl status --no-pager startup-demo.service
startup-demo.service - Startup demo service
     Loaded: loaded (/etc/systemd/system/startup-demo.service; enabled; preset: enabled)
     Active: active (running) since Tue 2026-04-14 04:11:44 UTC; 2s ago
   Main PID: 72 (sleep)

An active (running) state shows that the program started successfully in the current boot and should also be started automatically on the next boot because the unit is enabled.

Review the service logs from the current boot when the program should print a startup message or when troubleshooting is needed.
```
$ sudo journalctl -u startup-demo.service -b --no-pager
Apr 14 04:11:44 host.example.net systemd[1]: Started startup-demo.service - Startup demo service.
Apr 14 04:11:44 host.example.net startup-demo.sh[72]: startup-demo started
```
The -b flag limits the journal view to the current boot.

Related: How to manage a Linux service with systemctl

Author: Mohd Shakir Zakaria
Mohd Shakir Zakaria is a cloud architect with deep roots in software development and open-source advocacy. Certified in AWS, Red Hat, VMware, ITIL, and Linux, he specializes in designing and managing robust cloud and on-premises infrastructures.