Monday, January 18, 2016

Systemctl or Systemd Usage Guide on RHEL 7


Overview

Systemctl is a systemd utility which is responsible for controlling the systemd system and service manager.
Systemd is a collection of system management daemons, utilities and libraries which serves as a replacement of SystemV init daemon.
Systemd functions as central management and configuration platform for UNIX like system.

Applies To

Tested on RHEL 7, CentOS 7.

Pre-Requisites

  • None

Systemd – Generic Information

Version

To find the version of systemctl executable, run the command; 
 systemctl --version

Binaries

To find the binaries of systemctl executable, run the command;
whereis systemctl

Process System

To know the process associated with systemd run the command; 
ps -eaf | grep [s]ystemd

Systemd – Units

There are different units that are managed by systemd and it accepts following units.
Systemctl Units Purpose
systemd.service Manage System Service;
A unit configuration file whose name ends in .service encodes information about a process controlled and supervised by systemd.
systemd.socket Manage sockets for each service;
A unit configuration file whose name ends in ".socket" encodes information about an IPC or network socket or a file system FIFO controlled and supervised by systemd, for socket-based activation.
systemd.device Manage devices;
A unit configuration file whose name ends in ".device" encodes information about a device unit as exposed in the sysfs/udev device tree.
systemd.mount Manage mount points;
A unit configuration file whose name ends in ".mount" encodes information about a file system mount point controlled and supervised by systemd.
systemd.target Manage targets;
A unit configuration file whose name ends in ".target" encodes information about a target unit of systemd, which is used for grouping units and as well-known synchronization points during start-up.
Target units do not offer any additional functionality on top of the generic functionality provided by units. They exist merely to group units via dependencies (useful as boot targets), and to establish standardized names for synchronization points used in dependencies between units. Among other things, target units are a more flexible replacement for SysV runlevels in the classic SysV init system.
systemd.paths Check the existence of files or directories or create them as needed
systemd.slices Manage resources
systemd.snapshots Takes snapshots of the current state of the system
systemd.sockets Set up sockets to allow communication paths to processes that can remain in place, even if the underlying process needs to restart
systemd.swaps Create and use swap files or swap partitions
Systemd.timer Trigger actions based on a timer

Systemd – Boot Process

systemd is the first process started by the kernel. It replaces the venerable SysVinit program (also called init) and the newer Upstart init system. systemd coordinates the rest of the boot process and configures the environment for the user.

systemd improves on other init systems with increased parallelization. It starts the process of loading all programs it launches immediately, and manages information between interdependent programs as they load.

By dissociating programs and their means of communication, each program is able to load without waiting for unrelated or even dependent programs to load first.

Analyze systemd – Boot Process

To find out overall boot-up performance time consumption for the boot processes under different categories, run the command; 
systemd-analyze

This information are categorized under different heads such as;

  • kernel
  • initrd
  • userspace

Analyze systemd – Each Boot Process

You can also analyze boot-up performance, the time consumed by each task / service during the boot process. Run the command;
systemd-analyze blame

Analyze systemd – Critical Chain at Boot

To analyze the boot-up processes that’s critical for the booting the system in the current target, run the command; 
systemd-analyze critical-chain
Note: If the list is very long the overall boot process is extended / delay in system boot.
  • Time after the unit is active or started is printed after the "@" character.
  • Time the unit takes to start is printed after the "+" character.

Analyze systemd – Critical Chain by Service Unit

To analyze the boot-up process for a specific service unit and its critical chain, run the command; 
systemd-analyze critical-chain sshd.service


If the list is very long the overall boot process is extended / delay. In case of the specific service takes longer time to start, it would impact the overall booting of the server
  • Time after the unit is active or started is printed after the "@" character.
  • Time the unit takes to start is printed after the "+" character.

Analyze systemd – Critical Chain by Target

To list the “Critical Chain” for different targets, to know the analysis run the command; 
systemd-analyze critical-chain basic.target | grep target
Note:
  • Time after the unit is active or started is printed after the "@" character.
  • Time the unit takes to start is printed after the "+" character.

Systemd Units Commands

Units are the objects that systemd knows how to manage it. It’s standardized representation of system resources that can be managed by the suite of daemons and it can be manipulated by the provided utilities. Units in some ways can be said to similar to services or jobs in other init systems.

List Units – Available

Unit files allow systemd to address multiple units from a single configuration file. You can call a systemd template unit file. To list from the template, unit files configured on the system along with their current state of each unit run the command; 
systemctl list-unit-files


List Units – Running

Unit files allow systemd to address multiple units from a single configuration file. You can call a systemd template unit file. To list from the template, active state unit files configured on the system run the command;

systemctl list-units --state=active



List Units – Failed

Unit files allow systemd to address multiple units from a single configuration file. You can call a systemd template unit file. To list from the template, failed state unit files configured on the system run the command;

systemctl list-units --state=failed


List Units – By Type Service

Unit files that allow systemd to manage units. In case of wherein unit name that ends with “.service” encodes information about a process controlled and managed by systemd , to list service units run the command; 

systemctl list-units --type=service



List Units – By Type Mount

Unit files that allow systemd to manage units. In case of wherein unit name that ends with “.mount” encodes information about a process controlled and managed by systemd , to list mount points run the command;

systemctl list-unit-files --type=mount



List Units – By Type Socket

Unit files that allow systemd to manage units. In case of wherein unit name that ends with “.socket” encodes information an IPC or network socket or a file system FIFO controlled and supervised by systemd, for socket-based activation, to list sockets that are configured and enabled, run the command;

systemctl list-unit-files --type=socket









    List Units – By Type Slice


Unit files that allow systemd to manage units. In case of wherein unit name that ends with “.slice” encodes information about a slice
    which is a concept for hierarchically managing resources of a group of processes. This management is performed by creating a node in the Linux Control

Group (cgroup) tree, run the command;





systemctl list-unit-files --type=slice

















    List Units – By Type Swap


Unit files that allow systemd to manage units. In case of wherein unit name that ends with “.swap” encodes swap device or file for memory
    paging controlled and supervised by systemd, run the command;




systemctl list-unit-files --type=swap















    List Units – By Type Snapshot


Snapshot units are not configured via unit configuration files 
    . Nonetheless they are named similar to filenames. A unit whose name ends in ".snapshot" refers to a dynamic snapshot of the systemd    runtime state.Snapshots are not configured on disk but created dynamically via systemctl, run the command;




systemctl list-unit-files --type=snapshot

















    List Units – By Type Path


Unit files that allow systemd to manage units. In case of wherein unit name that ends with “.path” encodes information about path
    monitored by systemd, for path-based activation, run the command;




systemctl list-unit-files --type=path

















    List Units – By Type Timer


Unit files that allow systemd to manage units. In case of wherein unit name that ends with “.timer” encodes timer controlled and
    supervised by systemd, for timer-based activation.




systemctl list-unit-files --type=timer

















    So What’s systemctl / systemd unit Files


The unit files on your system determine how systemd will start and run. Each corresponds to a single activity or component or unit in
    systemd terms. 



    

  • 
        The global systemd configuration is stored in the /etc/systemd directory.
    
    • 


The service configuration files are located in the /usr/lib/systemd/system directory.

· Custom service configuration files are stored in the /etc/systemd/system directory.

Each unit file is a simple text file describing a unit, what it does, what needs to run before or afterward, and other details. Unit files can be stored in
    a few different places on your system. systemd looks for system unit files in the following order;





    


            Path
                
            Purpose
                
            Mode
                
        



            /etc/systemd/system
                
            Local Configuration
                
            System
                
        



            /run/systemd/system
                
            Run-time Units
                
            System
                
        



            /usr/lib/systemd/system
                
            Units provided by installed packages
                
            System
                
        




Depending on whether “--system” “--user” “--runtime” 
    or “--global” is specified, this enables the unit for the system, for the calling user only, for only this boot of the
    system, or for all future logins of all users, or only this boot.



Note:
   

In the last case, systemd daemon configuration is reloaded.
 
Similarly, systemd can also run in a user context and manage resources per user in addition to system-side. Unit files for user units are
    stored similarly in folders





    


            Path
                
            Purpose
                
            Mode
                
        



            /etc/systemd/user
                
            Local Configuration
                
            User
                
        



            /run/systemd/user
                
            Run-time Units
                
            User
                
        



            /usr/lib/systemd/user
                
            Units provided by installed packages
                
            User
                
        




Note
    : The order of precedence works similarly way.
 




    List Service – All Properties


List all the properties of a unit. It will display a list of properties that are set for the specified unit.





systemctl show rsyslogd --all



















    List Service – Specific Property - CPUShares


List a specific property of a service / unit, enter the attribute name. Run the command;







systemctl show rsyslogd -p CPUShares











Note:
   The default each service has a CPUShare = 1024. It can be configured to increase/decrease CPU share of a process.




    List Service – Specific Property - CanReload


List dependencies for a service / unit, if the service can automatically reload. Run the command;





systemctl show rsyslogd -p CanReload











    List Service – Specific Property - Conflicts


List dependencies for a service / unit, if the service can automatically reload. Run the command;


In case sshd.service conflicts, it will invoke shutdown.target which will shutdown the unit / service.





systemctl show sshd.service -p Conflicts















    Service Dependencies


One other information that can be collate or reviewed is dependencies for each target(s) or each unit(s).
 
Service dependencies allow you to conditionally include submodules and functionality, based on what the service / units library require.



There are two types systemd dependencies that exists between units:



v Dependencies that affect the activation of units, that are


Ø Requires


Ø Wants


Ø Conflicts


v Dependencies that affect the order of units, that are


Ø After


Ø Before








List Dependencies

To list the services, current target dependencies run the command;





systemctl list-dependencies















List Service Dependencies by Service 



To list the services dependencies run the command;





systemctl list-dependencies sshd.service















List Dependencies by Target

To list the target dependencies run the command;





systemctl list-dependencies graphical.target | grep target















List Service Dependencies – For Service

Show the service / unit dependencies. To know the dependencies of rsyslog.service, run the command;





systemctl list-dependencies rsyslog.service











List Service Dependencies – Before

List the units that are ordered after the specified unit.





systemctl list-dependencies rsyslog.service --before















List Service Dependencies – After

show the units that are ordered before the specified unit





systemctl list-dependencies rsyslog.service --after















List Service Dependencies – Reverse

Show reverse dependencies between units, List units with dependencies of type Wants= or Requires= on the given unit.









systemctl list-dependencies rsyslog.service --reverse















List Service Dependencies – Target

List critical chain for network and local-fs targets.




systemd-analyze critical-chain network.target local-fs.target















List Service Dependencies – Plot

Analyze systemd and plot into a file.




systemd-analyze plot > systemd_analyze_plot.svg















SlideShare Information

Step by step guide is uploaded.

 
















at




















No comments:
















Post a Comment