@brian-murray Hi. Tested that build, all seems fine, still no memory
leak.
# apt-cache policy systemd
systemd:
Installed: 245.4-4ubuntu3.13
Candidate: 245.4-4ubuntu3.13
Version table:
*** 245.4-4ubuntu3.13 500
500 http://archive.ubuntu.com/ubuntu focal-proposed/main amd64 Packages
100 /var/lib/dpkg/status
Test was performed like i was describe at original post, i run chef-
client and it start checking for all .service and .timers units, and it
cause memory leak, after upgrade no mem leak.
** Tags removed: verification-needed verification-needed-focal
** Tags added: verification-done verification-done-focal
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1935051
Title:
systemd pid 1 memory leak
Status in systemd package in Ubuntu:
Fix Released
Status in systemd source package in Focal:
Fix Committed
Bug description:
[impact]
pid1 leaks memory when rebuilding unit path cache
[test case]
see original description.
also, the patch contains an example of how to reproduce:
$ for i in {1..300}; do cp ~/.config/systemd/user/test0001.service
~/.config/systemd/user/test$(printf %04d $i).service; systemctl --user
start test$(printf %04d $i).service;done
[regression]
any problems would occur when rebuilding the path cache, possibly
resulting in memory leaks or pid1 crashes.
[scope]
this is needed only in f
fixed upstream by 3fb2326f3ed87aa0b26078d307ebfb299e36286d which is
included in v246, so fixed in h and later
the code in b is very different and doesn't appear to have the leak,
per original report
[original description]
Hi everybody.
We've meet a memory leak of pid1 process on the focal release.
When we launch chef-client, several systemd .service and .timers are checked
for state.
Every time of this run pid1 increase VSZ/RSS on ~ 232 Kb, this don't happen
on xenial and bionic releases.
I straced pid1 when that leak happen and found brk call.
On pmap view of pid 1 it's anon memory grow on the same address and all
marked as dirty.
All that leak memory can be freed by calling systemctl daemon-reexec.
Searching in systemd github repo i found this commit
https://github.com/systemd/systemd/commit/3fb2326f3ed87aa0b26078d307ebfb299e36286d
- it may be related to this leak.
------------------------------------------------------------------------
Environment:
Distributor ID: Ubuntu
Description: Ubuntu 20.04.2 LTS
Release: 20.04
Codename: focal
Uname: 5.4.0-77-generic #83-Ubuntu SMP Sat May 8 02:35:39 UTC 2021
x86_64
Package:
systemd:
Installed: 245.4-4ubuntu3.7
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1935051/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
