UNIX Startup Script

Have you seen some scenario when the server on which your application is hosted shut down due to any reason, be it Power Outage where the server exists or as per schedule.

If it is as per schedule then definitely you would have planned to start the hosted applications.

What if, the server shutdowns without your knowledge and the Server maintenance technicians start them up without having knowledge of starting your application residing in it?

Here we go with the Startup Script that can help you do anything you want to start along with making the server live. You would also get the term Bootstrap or Bootstraping scripts for scripts that run on booting the machine.

Prepare Bootstrap Script 

Let's first prepare a script that you want to run:

#!/bin/sh
echo "Vishesh : $(date)" > /etc/motd

This piece of code sets the message of the day to be the last reboot time so that each user can see it after their first login.

This command sets the date of server getting started when each user login.

Now lets check the approaches we can follow to setup this script to trigger each time server boots.

---------------------

cron feature

Let’s begin with the easiest solution, which involves using cron. In order to do that, we need to edit our crontab file:

$ crontab -e

Here, we’re just going to add a line using the @reboot expression, which will execute our code once at startup:

@reboot sh /home/ec2-user/reboot_message.sh

This solution is quick and clean since we don’t have to deal with additional configuration, but not every version of cron supports @reboot.

2.2. Using rc.local

Let’s now consider another solution that takes advantage of the /etc/rc.d/rc.local file. Since this file already runs at startup, we can append a line that invokes our script:

sh /home/ec2-user/reboot_message.sh

For this to work, though, we need to ensure that the rc.local file itself is executable:

$ chmod +x /etc/rc.d/rc.local

2.3. Using init.d

Similar to the previous solution, the /etc/init.d folder contains lifecycle executables of the services managed by the system. Furthermore, we can add our own by creating an LSB-compliant wrapper that starts our service:

#! /bin/sh
# chkconfig: 345 99 10
case "$1" in
  start)
    # Executes our script
    sudo sh /home/ec2-user/reboot_message.sh
    ;;
  *)
    ;;
esac
exit 0

This wrapper will launch our code when it’s invoked with the start argument. However, we must include a line with the chkconfig configuration, which contains the service runlevel and the start/stop priority.

After placing the wrapper in the init.d folder, we need to register our service for startup execution:

$ chkconfig --add service_wrapper.sh

Since the chkconfig command is not available on Debian systems, update-rc.d can be used as an alternative there:

$ update-rc.d service_wrapper.sh defaults

2.4. Using systems

Lastly, we’re going to see how to run a script with systemd. Similarly to init.d, we need to create a service descriptor – called a unit file – under /etc/systemd/system:

[Unit]
Description=Reboot message systemd service.

[Service]
Type=simple
ExecStart=/bin/bash /home/ec2-user/reboot_message.sh

[Install]
WantedBy=multi-user.target

The file is organized into different sections:

• Unit – contains general metadata, like a human-readable description
• Service – describes the process and daemonizing behavior, along with the command to start the service
• Install – enables the service to run at startup, using the folder specified in WantedBy to handle dependencies

To finish up, we need to set the file permissions to 644 and enable our service by using systemctl:

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

One thing to keep in mind is that although many major distributions support systemd, it’s not always available.

3. Conclusion

In this article, we took a look at different ways of executing a script at startup in Linux. Each one of them has its pros and cons, but generally speaking, systemd and cron should be preferred when available. Meanwhile, rc.local and init.d can be used as fallbacks.