Run a Command after BootStartup in Linux

How Can I Run a Command after Boot/Startup in Linux?

On boot/Startup time, you may like to add a well-known service that comes with its own script. Also, you might need to add a specific script or command, or service during boot/startup. How to Run a Command after Boot/Startup in Linux is what you will learn in this article. Tools or programs called Linux startup scripts are launched by the kernel each time your computer restarts. Once the system has been booted, users can use different Linux startup commands to configure programs or carry out specific tasks.

After buying Linux VPS and choosing your considered distribution, one of the interesting activities is that you have the option of instructing the operating system to carry out certain tasks at boot up, log on, and log out. Join us with this guide to review all the methods to execute a command or run scripts during a startup. In the end, you should be able to create customized startup jobs like launching your preferred Linux program.

Methods to AutoRun a Script on Startup or Reboot in Linux

To run a command or a script during a Linux startup, you can use seven different methods:

  1. /etc/rc.d/rc.local File (rc.local)
  2. Cron Job
  3. systemd service unit
  4. init.d
  5. .bashrc or .bash_profile
  6. Upstart
  7. Startup Applications

Run a Command after Boot/Startup in Linux [7 Methods]

Stay with us to learn how you can run a command or script when your Linux system starts up/reboots. This content covers seven different methods to run a command after booting in Linux. Check which one meets your needs and distro conditions.

1. Install and Use rc.local file to Run a Script on Startup in Linux

The init process is the first one to start when a Linux machine boot up. Depending on the state the computer is in at the time, the init process executes specific scripts. Runlevels are the names for these states. A sequence of rc scripts is run throughout each run level to prepare the system for use or a shutdown. The majority of UNIX operating systems should have access to the rc.local script file.

On contemporary Linux distributions, it might not be accessible by default, so we should be aware of that. Therefore, we will need to manually configure it. The system administrator will be granted access to run the rc.local script. Consequently, running a script or command as root is simpler. This method also works on the systemd system.

First, add a simple command to the script that you consider executing once the system starts up:

#!/bin/sh -e
# rc.local
# This script is executed at the end of each multiuser runlevel.
# Ensure that the script will "exit 0" on success or any other
# value on error.
# To enable or disable this script, just change the execution
# bits.
# By default, this script does nothing.
pgrep -x $(teamviewerd) || teamviewerd
exit 0

We added a line to the script that would launch the teamviewerd daemon as soon as the system boots up. Keep in mind that orders sent after exit 0 won’t be carried out. Even if the script’s commands are valid, this can happen occasionally. In that scenario, we should look at the file’s execution permissions and adjust them as necessary.

It is possible to enable rc-local Service on modern Linux distributions. You can run the rc.local script at startup if you make a straightforward “rc-local” systemd process. To do this, create a new file in the /etc/systemd/system/rc-local.service and put the following contents in the file:

Description=/etc/rc.local Compatibility

ExecStart=/etc/rc.local start



Then, you need to use systemctl to activate this service after saving the file.

$ systemctl enable rc.local

Create the rc.local file and grant it the necessary permissions after enabling the service.

2. Install and Use Cron Job to Run a Script on Startup in Linux

A file called a crontab provides a collection of commands that can be programmed to run on a regular basis. The cron jobs that we define in this file are the tasks. Previously, you learned How to use Cron Jobs In Linux And Schedule Tasks With It. A cron daemon, which is installed on the majority of distributions, typically runs them. There are various cron applications, all of which operate in the same manner and make use of the same crontab format. We must decide which one to use and how to setup it.

To install it on Ubuntu and Debian:

# apt install cronie

On Fedora and RHEL:

# yum install cronie

Once the installation is finished, proceed to check it:

$ crond -V

The crond service, which is essentially the daemon that will run when the system boots up, must now be enabled. So, type:

# systemctl enable crond

In this way, you can schedule cron jobs in the crontab from now on.

One or more lines can make up a simple crontab. Each line represents a routine task that is completed. Let’s use the crontab command to construct a crontab:

$ crontab -e

It should be an empty file first. To let it run each time the system starts up, use the commands below:

@reboot pulseaudio -k && pulseaudio
@reboot redshift -c ~/.config/redshift/config.conf

The time field and the command field are the two fields that make up a crontab entry. When to execute the associated command is specified by the time field. We added the symbol @reboot to our crontab to indicate that we want the actions to be executed when the system boots up. You should be aware that the aforementioned commands will be carried out as regular users. The -e option instructs crontab to alter the crontab for the current user. Run the crontab command as root to create a new crontab file specifically for the root user if you want to execute commands as root.

To create a task that runs a shell script as root on start-up, type:

$ sudo crontab -e

@reboot . /root/

If you wish to schedule the script to run at a different time or interval, @reboot can also be changed to a certain time or period.

3. Install and Use systemd to Run a Script on Startup in Linux

Systemd is the init and service manager used by the majority of popular Linux distributions. On startup, systemd has a unique method for running customized scripts. The majority of duties on Linux distributions are performed by systemd, which is more than just a service manager and an init system. Before systemd, we had to employ several tools for various tasks, some of which weren’t as efficient as systemd. Today, systemd is a component of all widely used Linux distributions, including Fedora, Ubuntu, Mint, Debian, and others. As a result, we should use it rather than relying on other tools.

To create the Start-Up script, First, you need a script file with the command(s) you want to run when the computer starts up. This file will later be designated to operate in a unique systemd service. Create a script file that essentially launches a notification daemon now and make sure to execute this script:

pgrep dunst || setsid -f dunst

As soon as your script is complete, you must establish a systemd service that uses it as a source. So let’s start by making a startup.service file in the /lib/systemd/system directory:

$ touch /lib/systemd/system/startup.service

In this way, you can create a systemd service. Then, define your service in this file:

Description=Startup Script

The location of our start-up script can be specified by modifying the ExecStart column. Save the file when finished, then turn on the service so that it starts up with our computer:

# systemctl enable startup.service --now

We’ve introduced the - now option and systemd will now enable and start this service. The same applies to creating many services that will launch at startup and serve various functions.

To run a script with systemd, you need to create a service descriptor called a unit file under /etc/systemd/system:

Description=Reboot message systemd service.
ExecStart=/bin/bash /home/ec2-user/

The document is divided into several sections:

  • Unit – includes generic metadata, such as a description that can be read by humans.
  • Service – provides information about the demonizing process and the command to start the service.
  • Install- allows the service to execute at startup while handling dependencies using the folder specified in WantedBy.

The next step is to use systemctl to enable our service and set the file permissions to 644.

$ chmod 644 /etc/systemd/system/reboot_message.service
$ systemctl enable reboot_message.service

4. Using init.d to Run a Script on Startup in Linux

The /etc/init.d folder houses lifecycle executables for the services that the system manages, just like the rc.local arrangement. By developing an LSB-compliant wrapper that launches our service, we may also add our own:

#! /bin/sh
# chkconfig: 345 99 10
case "$1" in
    # Executes our script
    sudo sh /home/ec2-user/
exit 0

When this wrapper is called with the start argument, our code will run. A line with the chkconfig setting, which specifies the service runlevel and the start/stop priority, must nevertheless be added. Once the wrapper has been added to the init.d folder, we must configure our service to run at startup:

$ chkconfig --add

Debian systems can use update-rc.d as a substitute as the chkconfig command isn’t accessible there:

$ update-rc.d defaults

5. Using .bashrc or .bash_profile to Run a Script on Startup in Linux

For the script to execute on each terminal login, add the command in your .bashrc or .bash_profile. Use .bash_profile or .bash_logout to run a script upon logon or logout, respectively. The latter file will probably need to be manually created. To get started, simply add a line to each file’s bottom that invokes your script in the same way as before.

6. Using Upstart to Run a Script on Startup in Linux

Numerous issues related to system V init are diminished and a great deal of customization is offered by the Upstart daemon. Upstart provides a flexible event-driven architecture and does not rely on obscure scripts to load services at startup. Additionally, configurations are added by way of a configuration file. As an illustration, the echo command is executed upon system startup by the following Upstart service.

In your /etc/init directory, first create the configuration file with a.end suffix. Since they are separate Linux file system directories, do not confuse them with /etc/init.d.

$ nano test.conf

description "testing Linux startup commands"

start on runlevel [2345]
stop on runlevel [!2345]

expect fork

exec echo "This is a test run!"

7. Using Startup Applications to Run a Script on Startup in Linux

With the help of the GUI tool Startup Applications Preferences, users in modern Linux distributions can define startup scripts or commands. Go to Activities > Type Startup > Select Startup Applications Preferences to locate it.

Using Startup Applications to Run a Script on Startup in Linux

Click the Add button in the sidebar once it is open. A new prompt will pop up, allowing you to add the startup script or command. Select your script by clicking Browse, then enter a brief description in the comment field. Don’t forget to give the position a name. To finish the process, click Add at the very end.

add linux startup scripts program

That’s that. At the end of all the above parts, you can restart your system to test that the script is being run on startup.


If you are unsure, it's a good idea to examine the documentation or speak with an expert. The process for running script on startup may differ based on the Linux distribution you are using.

Your choice of approach will be influenced by the particulars of your system and the script you're attempting to execute. It is crucial to remember that the script's path must be its complete path and not a relative path. You should also confirm that the script has execute permission.

This specific string enables users to run any command or script at boot time.


In this article, you found the answer to the question of ”How Can I Run a Command after Boot/Startup in Linux?”. Seven different methods were discussed to help you find the best and most suitable way of executing a command or script at reboot or startup in Linux.

Although each of them has advantages and disadvantages, systemd and cron should generally be preferred when they are available. Rc.local and init.d ought to be used as fallbacks as a result.