Click here to Skip to main content
65,938 articles
CodeProject is changing. Read more.
Articles / Languages / Python

A Note on CHKCONFIG & SYSTEMD

5.00/5 (1 vote)
29 May 2018CPOL5 min read 13.2K   37  
A discussion of auto-start services and how to manage and manually start/stop the services
The article provides an overview of managing auto-start services and manual start/stop procedures using CHKCONFIG and SYSTEMD on Linux. It covers topics such as creating service scripts, specifying run-levels and priority levels, managing services with CHKCONFIG, creating unit files and managing services with SYSTEMD.

Background

This is a discussion about CHKCONFIG & SYSTEMD. In the Redhat documentation, we can see the following sentences:

  • CHKCONFIG - The chkconfig utility is a command-line tool that allows you to specify in which runlevel to start a selected service, as well as to list all available services along with their current setting. Note that with the exception of listing, you must have superuser privileges to use this command;
  • SYSTEMD - Systemd is a system and service manager for Linux operating systems. It is designed to be backwards compatible with SysV init scripts, and provides a number of features such as parallel startup of system services at boot time, on-demand activation of daemons, or dependency-based service control logic. In Red Hat Enterprise Linux 7, systemd replaces Upstart as the default init system.

In this note, I will talk about auto-start services and how to manage and manually start/stop the services. I will use the following Python script file p-server.py as an HTTP server. My test platform is a CentOS 7 VM. If you do not like CentOS, you can use other Linux distributions. You may see some differences, but the idea should be the same.

Python
#!/usr/bin/python
    
import sys
import thread
import BaseHTTPServer
import SocketServer
    
args = sys.argv
    
PORT = int(args[1])
MSG = args[2]
    
class HttpHandler(BaseHTTPServer.BaseHTTPRequestHandler):
    def shutdown(self, server):
        server.shutdown()
    
    def do_GET(self):
        if self.path.startswith("/EXIT=Y"):        
            self.send_response(200)
                self.end_headers()
            self.wfile.write("Shutting down the server")
            thread.start_new_thread(self.shutdown, (httpd,))
        
        else:
            self.send_response(200)
                        self.end_headers()
                        self.wfile.write(MSG)    
    
SocketServer.TCPServer.allow_reuse_address = True
httpd = SocketServer.TCPServer(("", PORT), HttpHandler)    
    
print "serving at port", PORT
    
try:
    httpd.serve_forever()
except KeyboardInterrupt: pass
    
httpd.server_close()

In most Linux distributions, Python is installed by default. You can check if it is installed by the following command:

which python

You can use the following command to run the p-server.py file to start the HTTP server.

python p-server.py 12340 "Serving the HTTP GET request"
  • The first parameter 12340 is the port number that the server will be listening to;
  • The second parameter Serving the HTTP GET request is the text content that will be sent to the client from the server.

You can start the server and go to the URL "http://localhost:12340" to check if the server is functioning.

Image 1

You can use wget to send a request to shutdown the server.

wget -O/dev/null -q http://localhost:12340/EXIT=Y

Manage Services by CHKCONFIG

To create a service by CHKCONFIG, you can create a script file in the /etc/init.d directory. For simplicity, I just named it p-server-init.

Bash
#!/bin/bash
    
# description: p-server start/stop/restart
# chkconfig: 35 20 80
    
P_SERVER_HOME=/apps/simple-python-server
PORT=12341
RESPONSE_TEXT="Server started by CHKCONFIG"
    
case $1 in
start)
        nohup python $P_SERVER_HOME/p-server.py $PORT "$RESPONSE_TEXT" &
        ;;
stop)
        wget -O/dev/null -q http://localhost:$PORT/EXIT=Y
        ;;
restart)
        wget -O/dev/null -q http://localhost:$PORT/EXIT=Y
        sleep 2
        nohup python $P_SERVER_HOME/p-server.py $PORT "$RESPONSE_TEXT" &
        ;;
status)
        wget -qO- http://localhost:$PORT
        echo ""
        ;;
esac
    
exit 0 

We need to make it executable.

chmod +x p-server-init

We can then add it as a service by the CHKCONFIG command.

chkconfig --add p-server-init
chkconfig p-server-init on

If we now shutdown and restart the computer and go to the URL "http://localhost:12341/", we will find that the service is started when the computer starts.

The Run Levels

When you look at the p-server-init file, you may be confused about the following line:

# chkconfig: 35 20 80
  • The 35 indicates the run-levels when the service should be auto-started when the computer starts;
  • The "20 80" indicates priority levels to start and stop the service among all the services managed by CHKCONFIG.

According to the Redhat documentation, a run-level is an operation mode how the computer gets started.

Image 2

Among the 6 run-levels, the "Full multi-user text mode" and the "Full multi-user graphical mode" are the most common operation modes. In the p-server-init file, we instruct the system to start the service in both modes. Besides specifying the run-levels in the script file, we can use the following commands to control the run-levels in which a service should be started.

chkconfig --level 35 p-server-init off
chkconfig --level 35 p-server-init on

The Priority Levels

Among all the services managed by CHKCONFIG, the order of the start/stop may have some significance some times. The numbers specified in the p-server-init file is not exact. If we take a look at the /etc/init.d/network file that controls the startup of the network service, we can find that the network service will start with priority 10 and shutdown with priority 90.

# chkconfig: 2345 10 90

In the p-server-init file, we instructed the Python server should start after the network service by 20 and shutdown before the network service 80.

A Summary of CHKCONFIG Commands

As a summary, the following are the most commonly used CHKCONFIG commands.

chkconfig --list
chkconfig --add p-server-init
chkconfig --del p-server-init
chkconfig p-server-init on
chkconfig p-server-init off
service p-server-init start
service p-server-init stop
service p-server-init restart
service p-server-init status

Manage Services by SYSTEMD

In order to create a service by SYSTEMD, we can create a script file p-start.sh to start the Python server.

P_SERVER_HOME=/apps/simple-python-server
PORT=12342
RESPONSE_TEXT="Server started by SYSTEMD"

sleep 5
python $P_SERVER_HOME/p-server.py $PORT "$RESPONSE_TEXT"

We need to add a file p-server-system-d.service in the /etc/systemd/system directory.

[Unit]
Description=Python Server Service by SystemD
After=network.target
    
[Service]
Type=simple
ExecStart=/usr/bin/bash -c "/apps/simple-python-server/p-start.sh"
Restart=always
    
[Install]
WantedBy=multi-user.target

The p-server-system-d.service file is called a unit file. When you add or modify a unit file, you may need to issue the following command to refresh the SYSTEMD daemon.

systemctl daemon-reload

You can find this unit file by the following command:

systemctl list-unit-files | grep p-server-system-d.service

You can then start/stop/restart and check the status of the Python server by the following commands:

systemctl start p-server-system-d.service
systemctl stop p-server-system-d.service
systemctl restart p-server-system-d.service
systemctl status p-server-system-d.service 

If you want to enable/disable the service to start when the computer starts, you can issue the following commands.

systemctl enable p-server-system-d.service
systemctl disable p-server-system-d.service

Unit File Locations

According to this document, you can place your unit files in three locations:

  • /etc/systemd/system
  • /run/systemd/system
  • /lib/systemd/system

A unit file in the /etc directory has the highest priority, and the one in the /lib directory has the lowest priority. From my experience, you should put the actual unit file, but not a symlink to the unit file in these directories. When you install the Apache web server on your computer, the unit file associated with it is installed to the /lib/systemd/system directory.

SYSTEMD Targets

Similar to the run-levels in the CHKCONFIG, SYSTEMD uses targets to describe the running state of the computer and multiple targets can be active at the same time. You can check out the active targets by the following command:

systemctl list-units --type=target

The following are the active targets on my computer.

Image 3

In our unit file p-server-system-d.service, we instructed the SYSTEMD that the service should start after the network.target as part of the multi-user.target.

The "target.wants" Directories

If you issue the following command in the /etc/systemd/system directory, you can see a few directories named *.target.wants.

ls -l | grep target.wants

Image 4

  • When you enable the p-server-system-d.service, a symlink to the unit file is added to the multi-user.target.wants directory;
  • When you disable the p-server-system-d.service, the symlink is removed.

The *.target.wants directories are used by SYSTEMD to figure out when a service should be automatically started.

A Summary of SYSTEMD Commands

As a summary, the following are the most commonly used SYSTEMD commands.

systemctl status service-name
    
systemctl start service-name
systemctl stop service-name
systemctl restart service-name
systemctl status service-name
    
systemctl reload service-name
systemctl reload-or-restart service-name
    
systemctl enable service-name
systemctl disable service-name
    
systemctl is-active service-name
systemctl is-enabled service-name
systemctl is-failed service-name
    
systemctl list-unit-files
systemctl list-units
systemctl list-units --all
    
systemctl list-dependencies service-name
    
systemctl cat service-name
systemctl show service-name
systemctl mask service-name

Points of Interest

  • This is a note on CHKCONFIG and SYSTEMD;
  • I hope you like my posts and I hope this note can help you one way or the other.

History

  • 18th May, 2018: First revision

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)