It was observed that systemd-logind tool is leaking memory at each session
connected. The issue happens in systemd from Trusty (14.04), which latest
version currently (Feb/2018) is 204-5ubuntu20.26 (and still reproduces
the bug).
The basic test-case is to run the following loop from a remote machine:
while true; do ssh <hostname-target> "whoami"; done
and watch the increase in memory consumption from "systemd-logind" process
in the target machine. One can use the "ps uax" command to verify the
RSS of the process, or count the anon pages from /proc/<logind_pid>/smaps.
To clarify a bit how a session works, the following "stack trace" details
a bit which function calls happen when a SSH connection is opened, from
Trusty's systemd-logind point of view:
After each session is closed, it was observed that session_free() isn't
called, keeping the sessions alive. This can be verified through the
command "loginctl list-session" - each session that once connected is
present there "forever".
The memory leaks can eventually lead to OOM situation of this process.
Debug progress will be tracked here, in this LP.
It was observed that systemd-logind tool is leaking memory at each session
connected. The issue happens in systemd from Trusty (14.04), which latest
version currently (Feb/2018) is 204-5ubuntu20.26 (and still reproduces
the bug).
The basic test-case is to run the following loop from a remote machine:
while true; do ssh <hostname-target> "whoami"; done
and watch the increase in memory consumption from "systemd-logind" process logind_ pid>/smaps.
in the target machine. One can use the "ps uax" command to verify the
RSS of the process, or count the anon pages from /proc/<
To clarify a bit how a session works, the following "stack trace" details
a bit which function calls happen when a SSH connection is opened, from
Trusty's systemd-logind point of view:
main() <logind.c> message_ handler( ) create_ session( ) add_session( ) <logind.c> create_ fifo() create_ cgroup( )
manager_startup()
manager_run() [event-loop]
bus_loop_dispatch() <dbus-loop.c>
dbus_watch_handle() -> bus_manager_
bus_manager_
manager_
session_new() <logind-session.c>
session_
session_start()
session_
session_save()
session_bus_path()
[...]
After each session is closed, it was observed that session_free() isn't
called, keeping the sessions alive. This can be verified through the
command "loginctl list-session" - each session that once connected is
present there "forever".
The memory leaks can eventually lead to OOM situation of this process.
Debug progress will be tracked here, in this LP.