Hi Michael,
here is your requested output:
find /sys/fs/cgroup/system.slice/system-check_mk.slice/
produces:
root@debian:~# ls -la
/sys/fs/cgroup/systemd/system.slice/system-check_mk.slice/
total 0
drwxr-xr-x 8 root root 0 Sep 16 19:53 .
drwxr-xr-x 18 root root 0 Sep 16 19:53 ..
-rw-r--r-- 1 root root 0 Sep 16 19:53 cgroup.clone_children
-rw-r--r-- 1 root root 0 Sep 16 19:53 cgroup.procs
drwxr-xr-x 2 root root 0 Sep 16 19:53
check_mk@0-10.28.1.101:6556-10.28.1.99:61952.service
drwxr-xr-x 2 root root 0 Sep 16 19:53
check_mk@1-10.28.1.101:6556-10.28.1.99:61957.service
drwxr-xr-x 2 root root 0 Sep 16 19:53
check_mk@2-10.28.1.101:6556-10.28.1.99:61958.service
drwxr-xr-x 2 root root 0 Sep 16 19:53
check_mk@3-10.28.1.101:6556-10.28.1.99:61960.service
drwxr-xr-x 2 root root 0 Sep 16 19:53
check_mk@4-10.28.1.101:6556-10.28.1.99:61962.service
drwxr-xr-x 2 root root 0 Sep 16 19:53
check_mk@5-10.28.1.101:6556-10.28.1.99:61964.service
-rw-r--r-- 1 root root 0 Sep 16 19:53 notify_on_release
-rw-r--r-- 1 root root 0 Sep 16 19:53 tasks
systemctl status check_mk@0-10.28.1.101:6556-10.28.1.99:61952.service
produces:
root@debian:~# systemctl status
check_mk@0-10.28.1.101:6556-10.28.1.99:61952.service
* check_mk@0-10.28.1.101:6556-10.28.1.99:61952.service - Check_MK
Loaded: loaded (/etc/systemd/system/check_mk@.service; static; vendor
preset: enabled)
Active: inactive (dead)
Sep 16 19:52:26 debian systemd[1]: Started Check_MK (10.28.1.99:61952).
Sep 16 19:52:26 debian systemd[1]:
check_mk@0-10.28.1.101:6556-10.28.1.99:61952.service: Succeeded.
so systemctl status system-check_mk.slice
produces:
root@debian:~# systemctl status system-check_mk.slice
* system-check_mk.slice
Loaded: loaded
Active: active since Mon 2019-09-16 19:52:26 CEST; 4min 10s ago
Tasks: 0
Memory: 6.0M
CGroup: /system.slice/system-check_mk.slice
Sep 16 19:52:26 debian systemd[1]: Created slice
system-check_mk.slice.
While memory reported by "systemctl status system-check_mk.slice" grows
with each execution by call to the corresponding port (6556) of the
service.
Kind Regards,
Julian
------ Original Message ------
From: "Michael Biebl" <bi...@debian.org>
To: "Julian Hübenthal" <jul...@julian-huebenthal.de>;
940...@bugs.debian.org
Sent: 13/09/2019 00:55:16
Subject: Re: Bug#940021: systemd: socket activation leads to OOM
situation due to slices not getting cleaned up
Am 13.09.19 um 00:53 schrieb Michael Biebl:
Am 12.09.19 um 14:29 schrieb Michael Biebl:
Am 11.09.19 um 15:54 schrieb Julian Hübenthal:
Just discovered something that may help to debug:
It does not happen with a simple “Hello World” bash script instead of
the Check MK Agent.
It does not happen when the Encryption of the Check MK Agent is disabled.
It happens when the Encryption of Check MK is enabled, which should be
AES 128/256 output.
I wonder if the MK agent does some tricks like locking the memory when
encryption is on and then does not properly release its resources?
Just to ask the obvious: The slice(s) themselves are empty, i.e. the
check-mk agent process has exited (successfully)?
What's the status of such a service that is not cleaned up?
Taking your first email that would be
systemctl status check_mk@10-10.28.5.6:6556-10.28.5.1:42844.service
I'd be interested in the output of
find /sys/fs/cgroup/system.slice/system-check_mk.slice/ as well
As well as systemctl status system-check_mk.slice
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
