Bug#940021: Re[2]: Bug#940021: systemd: socket activation leads to OOM situation due to slices not getting cleaned up

[Julian Hübenthal]

Hi Michael,

here is your requested output:

  find /sys/fs/cgroup/system.slice/system-check_mk.slice/

produces:

root at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 0-10.28.1.101:6556-10.28.1.99:61952.service

produces:


root at debian:~# systemctl status 
check_mk at 0-10.28.1.101:6556-10.28.1.99:61952.service
* check_mk at 0-10.28.1.101:6556-10.28.1.99:61952.service - Check_MK
    Loaded: loaded (/etc/systemd/system/check_mk at .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 at 0-10.28.1.101:6556-10.28.1.99:61952.service: Succeeded.


so systemctl status system-check_mk.slice

produces:

root at 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" <biebl at debian.org>
To: "Julian Hübenthal" <julian at julian-huebenthal.de>; 
940021 at 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 at 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?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20190916/8c9d664b/attachment.html>