CENTos 7 – Using Systemctl

For this months technical blog thought I would share another difference between previous versions of the operating system.  Which is very different and can be very confusing for those of us used to the older ‘unix’ way of doing things.  RHEL 7, and therefor CENTos 7 have done away with the init.d method of boot scripts and starting and stopping services.  The OS now uses systemd (Similar to Apple’s launchd in OSX).  I will not be delving into the nuts and bolts of what systemd is, and how it works.  This is a simple run down of the commands you need to know to start, stop, and restart services using systemctl.  Additionally I will also cover systemd’s equivalent to runlevels, and how to change and set your systems default environment during boot.

Starting, Stopping, and Restarting Services.

In this article I assume that you are following best practices by logging in with a standard user account and evelating your privileges using sudo. If you are not, simply ignore the sudo command.

Starting a service.

Using init.d unix and Linux system, to start a service we would use the service command, which would execute it’s specific startup script. Whereas in CENTos 7 you would use systemctl.

Previous verions of CENTos –

               sudo service <service name> start

CENTos 7 –

               sudo systemctl start <service name>

Stopping a service.

Previous versions of CENTos –

               sudo service <service name> stop

CENTos 7 –

               sudo systemctl stop <service name>

Restarting a service.

Previous versions of CENTos –

               sudo service <service name> restart

CENTos 7 –

              sudo systemctl restart <service name>

This should all look pretty straight forward, you mostly just have to remember the new systemctl command, and the fact that you now place the action before service name.

Configuring boot services,

So how do we go about configuring which services are started at boot? With init.d you could either modify your init scripts for a specific runlevel, in the rc.d directory, or use a command called chkconfig which would handle it for you.

Previous versions of CENTos –

                sudo chkconfig –list sshd

    sshd                      0:off      1:off      2:on       3:on       4:on       5:on       6:off

 This shows us that the ssd service is either on or off in each corresponding runlevel. For instance runlevel 1 (Single User Mode), sshd is off at boot, however with run level (consoleonly, with networking services), sshd is on at boot.  I do find it interesting that sshd is configured to be on in runlevel 2 (Console only, no networking.)

You could easily toggle a specific service either on or off for each service with the following command.

                sudo chkconfig <service> --level <runlevels>

Full example given below.

                sudo chkconfig sshd –level 35

This would in effect, toggle the sshd service to be started at boot in both run revel 3 (Multi-User, with networking, in console mode.), and runlevel 5 (Multi-User, with networking, in Graphical Environment Mode (XWindows).

CENTos 7 –

In CENTos 7, You no longer have runlevels, so you only need to worry about a service being on or off (Or enabled or disabled), again using the systemctl command.

To configure a service to be started at boot.

                systemctl enable <service name>

Full example given below. Using the secure shell daemon.

               sudo systemctl enable sshd

To no longer have a service started at boot.

                systemctl disble <service name>

Full example given below, Using the secure shell daemon.

                sudo systectl disable sshd

Displaying a list of running services.

You can get the status of the running services or a single service by the following 2 methods.                 

                  systemctl status

Will return the status of every running service, and its dependents.

                  systemctl status <service>

Will display the status of an individual service (such as winbind shown here).

├─winbind.service
             │ ├─17859 /usr/sbin/winbindd
             │ ├─17998 /usr/sbin/winbindd
             │ ├─19090 /usr/sbin/winbindd
             │ ├─19398 /usr/sbin/winbindd
             │ └─19854 /usr/sbin/winbindd

The last bit I will demonstrate with system control is how to switch between a console (Command Line) environment, and how to set the default runrevel.
First let’s find out what runlevel we are current using.

                   sudo systemctl get-default

The system will return the current target mode

multi-user.target

This is the old runrevel 3, (command line, multi user with networking).
So let’s say we wanted to switch to the old runlevel 5 “Multiuser, Networking, with Xwindows”

We can have centOS return a list of available “TARGETS” (runlevels), You do not need to run this command as root, so no sudo is necessary.

systemctl list-units –t target -a

UNIT LOAD      ACTIVE   SUB    DESCRIPTION
target           loaded    active   active Basic System
target      loaded    active   active Encrypted Volumes
target       loaded    inactive dead   Emergency Mode
target           loaded    inactive dead   Final Step
target           loaded    active   active Login Prompt
target       loaded    inactive dead   Graphical Interface
local-fs-pre.target    loaded    active   active Local File Systems (Pre)
local-fs.target        loaded    active   active Local File Systems
multi-user.target      loaded    active   active Multi-User System
network-online.target  loaded    active   active Network is Online
network-pre.target     loaded    inactive dead   Network (Pre)
target         loaded    active   active Network
nss-lookup.target      loaded  inactive dead   Host and Network Name Lookups
nss-user-lookup.target loaded    inactive dead   User and Group Name Lookups
target           loaded    active   active Paths
remote-fs-pre.target   loaded    inactive dead   Remote File Systems (Pre)
remote-fs.target       loaded    active   active Remote File System
target          loaded    inactive dead   Rescue Mode
target        loaded    inactive dead   Shutdown
target          loaded    active   active Slices
target         loaded    active   active Sockets
target           loaded    active   active Sound Card

For the old runlevel 5, (Xwindows, Multi-User, With Networking) we would issue the following command. As this will manipulate services, we must run this as root.
                   sudo systemctl isolate graphical.target

To switch back to runlevel 3  ‘multi-user target’
sudo systemctl isolate multiuser.target

Now that we can switch between targets “Runlevels” let’s set one as a default.

Remember we mentioned in the beginning of the blog that CentOS 7 now uses systemd and not init.d to control the boot process. Systemd uses a symbolic link to determine the systems default target”  If you do an ls-l or ll on /etc/systemd/system, you can determine the systems default target.
                  ll /etc/systemd/system

• 1 root root 41 Jan  4 04:20 default.target -> /usr/lib/systemd/system/multi-user.target

First we must remove the symbolic link

                  sudo rm/etc/systemd/system/default.target

Now we create a new symbolic link to the ‘graphical.tartarget’

sudo ln-sf /lib/systemd/system/graphical.target /etc/systemd/system/default.target

Before we reboot the system, let’s make sure the default target symbolic link was correctly set.

                 ll /etc/systemd/system/

We should now see this

lrwxrwxrwx 1 root root   36 Jan 23 11:13 default.target – /lib/systemd/system/graphical.target

Let’s go ahead and reboot the system, and it should now boot into the GUI (XWindows                  

                 sudo reboot

To return the system to boot into a multi-user console with networking, repeat the steps above, substituting ‘multi-user.target’ in place of graphical.target.  Like this.

sudo ln-sf /lib/systemd/system/multi-user/target /etc/systemd/system/default.target

 

You should now have a better grasp on how to control services, and your default run level using CentOS 7.

I hope you enjoyed this month’s technical blog, and will continue to return for more exciting and informative articles. All comments are welcome.

DISCLAIMER: While we strive to bring you the most accurate information, use these commands at your own risk.  Neither the authors nor Brent’s World are responsible for any damage, or loss of data, nor loss of revenue resulting in downtime, either expected or unexpected that may occur by using the commands outlined in this blog.  It is recommended that these commands or scripts be executed in a test environment (Preferably on a virtual machine, not connected to an active network), until you fully understand the actions being performed by the commands or scripts.