Open jciesla opened 1 year ago
jelly
commented
1 year ago Some things which might be interesting for us to debug this issue:
jciesla
commented
1 year ago Hello @jelly,
This is the systemd version :
admin@hw-ovf21:~$ systemctl --version
systemd 250 (250.5+)
+PAM -AUDIT -SELINUX -APPARMOR +IMA -SMACK -SECCOMP -GCRYPT -GNUTLS -OPENSSL -ACL +BLKID -CURL -ELFUTILS -FIDO2 -IDN2 -IDN -IPTC +KMOD -LIBCRYPTSETUP +LIBFDISK +PCRE2 -PWQUALITY -P11KIT -QRENCODE -BZIP2 -LZ4 +XZ -ZLIB -ZSTD -BPF_FRAMEWORK -XKBCOMMON +UTMP +SYSVINIT default-hierarchy=unified
admin@hw-ovf21:~$I stripped down the most of cockpit folders to isolate the issue and restarted cockpit before to login :
root@hw-ovf21:/usr/share/cockpit# ls -l
total 32
drwxr-xr-x 2 root root 4096 Mar 9 2018 base1
drwxr-xr-x 14 root root 4096 Mar 9 2018 branding
drwxr-xr-x 2 root root 4096 Mar 9 2018 metrics
drwxr-xr-x 2 root root 4096 Mar 9 2018 motd
drwxr-xr-x 3 root root 4096 Mar 9 2018 shell
drwxr-xr-x 2 root root 4096 Mar 9 2018 ssh
drwxr-xr-x 3 root root 4096 Mar 9 2018 static
drwxr-xr-x 2 root root 4096 Mar 9 2018 systemd
root@hw-ovf21:/usr/share/cockpit#When I log in, I use a user authorized on the system sudoers (admin), and administrative rights has been enabled. I only log into the overview page and do not click anywhere.
the [python]-bridge process leaking is the one associated to the admin user (the bridge for root user do not leak).
On the browser, I see these errors.
encbar5
commented
1 month ago @jelly This does appear to still be an issue, except that on my system the leak is occurring for the process owned by the root user. I have an ARM system (aarch64) using Debian 12, and both the C bridge and python bridge appear to have leaks. Steps were to log in to a Cockpit session from a Firefox tab, make sure the session had administrative privileges, and then open a web terminal. No other interaction with the cockpit interface was necessary. The tab was then left open.
Using cockpit version 287.1 from bookworm, the cockpit-bridge --privileged process almost doubles the resident set in 50 minutes, from 7.8Mb to 14Mb.
Mon 15 Jul 19:26:30 CDT 2024
root 2578 1.8 0.2 310176 7836 ? Sl 19:26 0:00 cockpit-bridge --privileged
Mon 15 Jul 20:17:24 CDT 2024
root 2578 0.1 0.3 311140 14108 ? Sl 19:26 0:03 cockpit-bridge --privilegedThen testing the 320 version from bookworm-backports, it is using the python bridge, which started at higher memory, 28Mb. This did not change after 50 minutes, but then I clicked a few more buttons in the Cockpit UI, opened a web terminal, and left it for several more hours, which resulted in a resident set of 100Mb.
Mon 15 Jul 20:21:28 CDT 2024
root 10276 2.3 0.7 41648 28672 ? S 20:20 0:00 /usr/bin/python3 /usr/bin/cockpit-bridge --privileged
Mon 15 Jul 21:14:08 CDT 2024
root 10276 0.1 0.7 41648 28672 ? S 20:20 0:04 /usr/bin/python3 /usr/bin/cockpit-bridge --privileged
Tue 16 Jul 05:45:25 CDT 2024
root 10276 0.1 2.5 113988 100608 ? S Jul15 0:54 /usr/bin/python3 /usr/bin/cockpit-bridge --privileged
Hello,
Hello, I currently have an issue for which I try to find the origin. It does not matter if it is for use with cockpit-bridge or python-bridge, when a user session remains open for a certain time, the consumption of the associated process constantly increases (cockpit-bridge or python), until a memory failure occurs (by example with oom killer).
I found that if I remove the systemd package from my system (delete the "/usr/share/cockpit/systemd"), I no longer haves the memory leak. All other packages working correctly without any issue, even with sessions maintained for long periods.
I try with each new cockpit version and I thought that the new python-bridge might be able to solve the situation but unfortunately the results are the same.
The last version I tried is 295. I use a custom Linux distribution for industrial use, running kernel 5.19 (Linux 5.19.17-rt10 #1 SMP PREEMPT_DYNAMIC x86_64 x86_64 x86_64 GNU/Linux)
Maybe someone can give me an idea or help me to identify the issue. Thanks!