http://linuxaria.com/article/how-to-manage-processes-with-cgroup-on-systemd
systemd is a suite of system management daemons, libraries, and utilities designed as a central management and configuration platform for the GNU/Linux computer operating system.
It provides a system and service manager that runs as PID 1 and starts the rest of the system as alternative to the traditional sysVinit.
systemd provides aggressive parallelization capabilities, uses socket and D-Bus activation for starting services, offers on-demand starting of daemons,
It’s becoming the standard of all the major GNU/Linux distributions and at the moment it’s the default for Arch Linux, Red Hat Enterprise/Centos (version 7), Fedora, Mageia and Suse Enterprise, it’s planned to be used on Debian 8 and Ubuntu 15.04.
There is a lot of people talking for and against systemd on the net as some see it as too intrusive, complex and against the Unix philosophy to keep things simple and make them do just one task.
Using Red Hat 7 at work and Arch Linux on my laptop I’ve started to use it and I must agree that it’s not so simple in the start, but let’s try to take the good thing from it and in this article I’d like to show you some commands that you can use with systemd to manage the processes on a GNU/Linux system and that I’ve found really useful.
Control groups can be used in multiple ways:
You can see the sue of cgroups with the ps command, which has been updated to show cgroups. Run this command to see which service owns which processes:
In the third column you see the cgroup systemd assigned to each process. You’ll find that the udev processes are in the name=systemd:/systemd-1/sysinit.service cgroup, which is where systemd places all processes started by the sysinit.service service, which covers early boot.
A different way to present the same information is the systemd-cgls tool that is shipped with systemd. It shows the cgroup hierarchy in a pretty tree. Its output looks like this:
this command shows the processes by their cgroup and hence service, as systemd labels the cgroups after the services. For example, you can easily see that the auditing service auditd.service spawns three individual processes, auditd, audisp and sedispatch.
When you need to kill a service you can kill the cgroup name, so you don’t have to search all the pid or use commands such as killall or pgrep, as example to kill all the processes of the service auditd you can use the command:
No more ps -ef |grep something| awk something |kill the result of the awk![:)]()
Unfortunately, by default cgtop will only be able to chart CPU usage per-service for you, IO and Memory are only tracked as total for the entire machine. The reason for this is simply that by default there are no per-service cgroups in the blkio and memory controller hierarchies but that’s what is needed to determine the resource usage.
If resource monitoring for these resources is required it is recommended to add blkio and memory to the DefaultControllers= setting in /etc/systemd/system.conf (see systemd.conf(5) for details). Alternatively, it is possible to enable resource accounting individually for services, by making use of the ControlGroup= option in the unit files (See systemd.exec(5) for details).
To emphasize this: unless blkio and memory are enabled for the services in question with either of the options suggested above no resource accounting will be available for system services and the data shown by systemd-cgtop will be incomplete.
Resources
From the creator of systemd:
systemd is a suite of system management daemons, libraries, and utilities designed as a central management and configuration platform for the GNU/Linux computer operating system.
It provides a system and service manager that runs as PID 1 and starts the rest of the system as alternative to the traditional sysVinit.
systemd provides aggressive parallelization capabilities, uses socket and D-Bus activation for starting services, offers on-demand starting of daemons,
It’s becoming the standard of all the major GNU/Linux distributions and at the moment it’s the default for Arch Linux, Red Hat Enterprise/Centos (version 7), Fedora, Mageia and Suse Enterprise, it’s planned to be used on Debian 8 and Ubuntu 15.04.
There is a lot of people talking for and against systemd on the net as some see it as too intrusive, complex and against the Unix philosophy to keep things simple and make them do just one task.
Using Red Hat 7 at work and Arch Linux on my laptop I’ve started to use it and I must agree that it’s not so simple in the start, but let’s try to take the good thing from it and in this article I’d like to show you some commands that you can use with systemd to manage the processes on a GNU/Linux system and that I’ve found really useful.
Processes and cgroups
systemd organizes processes with cgroups, this is a Linux kernel feature to limit, police and account the resource usage of certain processes (actually process groups). Compared to other approaches like the ‘nice’ command or/etc/security/limits.conf, cgroups are more flexible.Control groups can be used in multiple ways:
- create and manage them on the fly using tools like
cgcreate,cgexec,cgclassifyetc - the “rules engine daemon”, to automatically move certain users/groups/commands to groups (
/etc/cgrules.confand/usr/lib/systemd/system/cgconfig.service) - through other software such as Linux Containers (LXC) virtualization
You can see the sue of cgroups with the ps command, which has been updated to show cgroups. Run this command to see which service owns which processes:
$ ps xawf -eo pid,user,cgroup,args |
A different way to present the same information is the systemd-cgls tool that is shipped with systemd. It shows the cgroup hierarchy in a pretty tree. Its output looks like this:
$ systemd-cgls |
When you need to kill a service you can kill the cgroup name, so you don’t have to search all the pid or use commands such as killall or pgrep, as example to kill all the processes of the service auditd you can use the command:
# systemctl kill auditd.serviceThis will ensure that SIGTERM is delivered to all processes of the auditd service, not just the main process. Of course, you can also send a different signal if you wish.
# systemctl kill -s SIGKILL auditd.serviceSometimes all you need is to send a specific signal to the main process of a service, maybe because you want to trigger a reload via SIGHUP. Instead of going via the PID file, here’s an easier way to do this:
# systemctl kill -s HUP –kill-who=main crond.serviceAnd in my point of view this is great !
No more ps -ef |grep something| awk something |kill the result of the awk
Analyzing Resource usage
To understand the resource usage of all services, the systemd developers created the tool systemd-cgtop, that will enumerate all cgroups of the system, determine their resource usage (CPU, Memory, and IO) and present them in a top-like fashion. Building on the fact that systemd services are managed in cgroups this tool hence can present to you for services what top shows you for processes.Unfortunately, by default cgtop will only be able to chart CPU usage per-service for you, IO and Memory are only tracked as total for the entire machine. The reason for this is simply that by default there are no per-service cgroups in the blkio and memory controller hierarchies but that’s what is needed to determine the resource usage.
If resource monitoring for these resources is required it is recommended to add blkio and memory to the DefaultControllers= setting in /etc/systemd/system.conf (see systemd.conf(5) for details). Alternatively, it is possible to enable resource accounting individually for services, by making use of the ControlGroup= option in the unit files (See systemd.exec(5) for details).
To emphasize this: unless blkio and memory are enabled for the services in question with either of the options suggested above no resource accounting will be available for system services and the data shown by systemd-cgtop will be incomplete.
Resources
From the creator of systemd:
- Rethinking PID 1
- systemd for Administrators, Part 1
- systemd for Administrators, Part II
- systemd for Administrators, Part III
- systemd for Administrators, Part IV
- systemd for Administrators, Part V
- systemd for Administrators, Part VI
- systemd for Administrators, Part VII
- systemd for Administrators, Part VIII
- systemd for Administrators, Part IX
- systemd for Administrators, Part X
- systemd for Administrators, Part XI