The author selected the Free and Open Source Fund to receive a donation as part of the Write for DOnations program.

Introduction

In this tutorial you will use systemd to configure MySQL to restart automatically after a reboot or crash.

This is the second half of a two-part series. Part One covers general Linux service management concepts like the init daemon and runlevels. It ends with a demonstration of service management in systemd. Here you will examine targets, wants, requires, and unit files. This part, part two, provides a practical example using the MySQL database.

Note: You might also consider reading our very popular tutorial on using systemctl to control systemd services and units.

Prerequisites

To complete this tutorial, you will need:

• A server running CentOS 8, including a non-root user with sudo privileges. To set all this up, including a firewall, you can create a DigitalOcean Droplet running CentOS 8 and then follow our Initial Server Setup Guide.

• MySQL installed. For detailed instructions, follow our tutorial, How To Install MySQL on CentOS 8.

Configuring MySQL To Auto-start After Boot using systemd

With MySQL installed, check the status of your service:

The output should show that the service is running, but the daemon is disabled:

If the service is enabled, disable it. We want to first explore the disabled behavior before making our changes:

Next, run this command to check if MySQL is wanted by multi-user.target:

Nothing will return. Now check if the symbolic link exists:

A message appears stating that the symlink file does not exist:

Now, if you like, reboot the server and check the MySQL service. It should not be running.

Whether you rebooted or not, now re-enable the MySQL service:

This time, the system will create a symbolic link under /etc/systemd/system/multi-user.target.wants/:

Run the ls command again to confirm this:

You will receive an output like this:

Enabling or disabling a systemd service creates or removes the symbolic link from the default target’s wants directory.

If you like, reboot the Droplet again, and when it comes back online run the ps -ef command to check the service status.

This command will provide information about MySQL, if it is running:

You have now configured MySQL to restart after a reboot. Next you will account for crashes.

Configuring MySQL To Auto-start After a Crash Using systemd

Being a modern application, MySQL already comes configured to auto-start after a crash. Let’s see how to disable that.

Open the MySQL service unit file in an editor:

After the header information, the contents of the file looks like this:

[Unit]

Description=MySQL 8.0 database server
After=syslog.target
After=network.target

[Service]

Type=notify
User=mysql
Group=mysql

ExecStartPre=/usr/libexec/mysql-check-socke
ExecStartPre=/usr/libexec/mysql-prepare-db-dir %n
`# Note: we set --basedir to prevent probes that might trigger SELinux alarms,`
`# per bug #547485`
ExecStart=/usr/libexec/mysqld --basedir=/usr
ExecStartPost=/usr/libexec/mysql-check-upgrade
ExecStopPost=/usr/libexec/mysql-wait-stop

`# Give a reasonable amount of time for the server to start up/shut down`

TimeoutSec=300

`# Place temp files in a secure directory, not /tmp`

PrivateTmp=true

Restart=on-failure

RestartPreventExitStatus=1

`# Sets open_files_limit`

LimitNOFILE = 10000

`# Set enviroment variable MYSQLD_PARENT_PID. This is required for SQL restart command.`

Environment=MYSQLD_PARENT_PID=1

[Install]

WantedBy=multi-user.target

As you can see the value of the Restart parameter is set to on-failure. This means the MySQL service will restart for unclean exit codes or timeouts.

The man page for systemd service shows the following table for Restart parameters:

Restart settings/Exit causes no always on-success on-failure on-abnormal on-abort on-watchdog Clean exit code or signal

X X

Unclean exit code

X

X

Unclean signal

X

X X X

Timeout

X

X X

Watchdog

X

X X

X

In a systemd service unit file, two parameters - Restart and RestartSec - control crash behavior. The first parameter specifies when the service should restart, and the second parameter defines how long it should wait before restarting.

To test the crash behavior, stop the MySQL process with a kill -9 signal. In our case the main PID is 851; replace the PID with your own:

ps -ef | grep mysql

Wait for a few seconds and then check the status:

The output will show that MySQL has restarted with a new PID (in our case the new Process ID is 1513):

Next, reopen the unit file:

Comment out the Restart directive in the MySQL daemon’s unit file and save it. This will disable the restart behavior:

`# Restart=on-failure`

After this, reload the systemd daemon, followed by a restart of the mysqld service:

You can find the main PID of the service by running this command:

Using the kill -9 command, kill the main PID of the MySQL PID in your environment (we are using the PID in our test environment).

sudo kill -9 1895

Check the status for MySQL:

It will show that the service has failed:

Try to find the service status a few times. Each time the service will show as failed.

So, we have emulated a crash where the service has stopped and hasn’t come back. This is because we have instructed systemd not to restart the service after an unclean stop. If you edit the mysqld.service unit file to uncomment the Restart parameter, save it, reload the systemctl daemon, and finally restart the service, that will restore normal function.

This is how you can configure a native systemd service to auto-start after a crash. All you have to do is add an extra directive for Restart (and optionally RestartSec) under the [Service] section of the service unit file.

Conclusion

In this two-part series, you learned about the service management daemons used across the Linux ecosystem. You then explored the fundamentals of systemd and applied those fundamentals to a practical example: configuring a database to restart after a reboot or crash. If you wish to learn more about systemd, consider exploring our comprehensive tutorial on using systemctl.