Changing the Default Target of a System

Hands-On Lab

 

Photo of Terrence Cox

Terrence Cox

Senior Vice President of Content

Length

00:30:00

Difficulty

Intermediate

Runlevels have changed significantly as Linux distributions have migrated from sysvinit to systemd. Understanding how runlevels are configured in systemd is paramount to successfully making that transition. After completing this activity, the student will have a firm understanding of how the new system 'targets' control the runlevels of your distribution.

What are Hands-On Labs?

Hands-On Labs are scenario-based learning environments where learners can practice without consequences. Don't compromise a system or waste money on expensive downloads. Practice real-world skills without the real-world risk, no assembly required.

Changing the Default Target of a System

Our development team is building a new Web-based API, and they've customized an entire runlevel that they want it to boot into automatically.

They've given us login credentials for the system that will be using this new default runlevel. The team built a new target file for us to install, and they placed it in our home directory. We need to install it in the proper system directory, paying attention to file ownership and permission.

Once we've got the file where it belongs, we'll need to set custom.target as the system's new default boot target. After we issue the command to finalize the change, we can turn the system back over to the team.

Before we Begin

Before we can get started, we need to log in as the root user using sudo:

[cloud_user@$host ~]$ sudo su -

When prompted, enter the provided lab credentials to finish logging in.

Locating Our File

First, let's see where things are located. Using the pwd command, find out where we are in the filesystem:

[cloud_user@$host ~]$ pwd
/home/cloud_user

Great, now let's make sure that the file we need is in here like the Dev team said it would be using the ls command:

[cloud_user@$host ~]$ ls
custom.target

OK, everything (including our filesystem path) is as it should be.

Set up Our File

Now we need to get the file to where it belongs. The file custom.target needs to be in the /etc/systemd/system/ before it will run, so let's copy it over using the cp command:

[cloud_user@$host ~]$ sudo cp custom.target /etc/systemd/system/
[sudo] password for cloud_user:

It also needs to be executable. To do that, use the chmod command:

[cloud_user@$host ~]$ sudo chmod u+x /etc/systemd/system/custom.target

For systemd to recalculate all the dependencies involving this new custom target, we'll need to run the daemon-reload command:

[cloud_user@$host ~]$ sudo systemctl daemon-reload

Then we'll actually set the default target to this new custom target using sudo and systemctl set-default for the file:

[cloud_user@$host ~]$ sudo systemctl set-default custom.target
Removed symlink /etc/systemd/system/default.target.
Created symlink from /etc/systemd/system/default.target to /etc/systemd/system/custom.target.

A Small Test

With everything set up, we should verify that the desired new default target is, in fact, the new default with the get-default command:

[cloud_user@$host ~]$ sudo systemctl get-default
custom.target

It is, so now we can hand things back to the development team.

Review

In this lab, we changed the default target that the operating system will boot into. This will give the Dev team's app all of the requirements it needs in order to run at boot. Congratulations! The Dev team can get back to work now.