I have not yet had the chance to migrate this system to boot with systemd. The problem is also not yet resolved. However, the logind processes now consume far less RAM:
$ ps auxww | grep logind root 503 0.0 0.0 28388 2892 ? S Nov27 0:00 /lib/systemd/systemd-logind root 1665 0.0 0.0 28388 2996 ? S Nov27 0:00 /lib/systemd/systemd-logind root 1756 0.0 0.0 28388 2976 ? S 16:18 0:00 /lib/systemd/systemd-logind jgoerzen 3283 0.0 0.0 12720 2252 pts/4 S+ 16:56 0:00 grep logind root 4260 0.0 0.0 28356 2900 ? S Nov26 0:00 /lib/systemd/systemd-logind root 4357 0.0 0.0 28388 2996 ? S Nov28 0:00 /lib/systemd/systemd-logind root 4861 0.0 0.0 28388 2916 ? S 07:18 0:00 /lib/systemd/systemd-logind root 4969 0.0 0.0 28388 2924 ? S Nov28 0:00 /lib/systemd/systemd-logind root 6062 0.0 0.0 28388 3020 ? S Nov27 0:00 /lib/systemd/systemd-logind root 7394 0.0 0.0 28536 3156 ? S Nov27 0:00 /lib/systemd/systemd-logind root 10347 0.0 0.0 28388 2940 ? S Nov27 0:00 /lib/systemd/systemd-logind root 11349 0.0 0.0 28388 2980 ? S Nov28 0:00 /lib/systemd/systemd-logind root 11368 0.0 0.0 28388 2924 ? S Nov28 0:00 /lib/systemd/systemd-logind root 13397 0.0 0.0 28388 3028 ? S Nov27 0:00 /lib/systemd/systemd-logind root 14562 0.0 0.0 28388 2988 ? S Nov26 0:00 /lib/systemd/systemd-logind root 15616 0.0 0.0 28388 3032 ? S 09:19 0:00 /lib/systemd/systemd-logind root 16399 0.0 0.0 28388 2968 ? S Nov27 0:00 /lib/systemd/systemd-logind root 17532 0.0 0.0 28388 2940 ? S 00:19 0:00 /lib/systemd/systemd-logind root 17807 0.0 0.0 28388 3024 ? S Nov28 0:00 /lib/systemd/systemd-logind root 20332 0.0 0.0 28388 3036 ? S Nov27 0:00 /lib/systemd/systemd-logind root 20692 0.0 0.0 28388 2952 ? S Nov26 0:00 /lib/systemd/systemd-logind root 21986 0.0 0.0 28388 2972 ? S 12:17 0:00 /lib/systemd/systemd-logind root 22824 0.0 0.0 28388 2940 ? S Nov27 0:00 /lib/systemd/systemd-logind root 23886 0.0 0.0 28388 3032 ? S Nov28 0:00 /lib/systemd/systemd-logind root 24545 0.0 0.0 28388 2980 ? S 03:00 0:00 /lib/systemd/systemd-logind root 26550 0.0 0.0 28388 3028 ? S Nov27 0:00 /lib/systemd/systemd-logind root 27408 0.0 0.0 28388 2956 ? S Nov26 0:00 /lib/systemd/systemd-logind root 27965 0.0 0.0 28388 2944 ? S 14:17 0:00 /lib/systemd/systemd-logind root 27978 0.0 0.0 28616 3136 ? S Nov28 0:00 /lib/systemd/systemd-logind root 30090 0.0 0.0 28388 2908 ? S Nov28 0:00 /lib/systemd/systemd-logind root 30738 0.0 0.0 28388 2912 ? S 05:17 0:00 /lib/systemd/systemd-logind root 31298 0.0 0.0 28388 2940 ? S Nov27 0:00 /lib/systemd/systemd-logind So the problem is not nearly so bad any more. John On 11/20/2014 03:11 PM, Sjoerd Simons wrote: > Hey John, > > On Sun, Nov 09, 2014 at 06:13:30PM -0600, John Goerzen wrote: >> I will try this. It is a bit complicated because the system in question >> is also running ZFS and there are some bugs with that boot, but I think >> I have worked them out enough. It may take me a few days to find the >> time, however. > Did you find the time to get this system booting with systemd? Would be great > to further narrow it down. > > >> On 11/03/2014 08:43 PM, Michael Biebl wrote: >>> Am 18.10.2014 um 21:49 schrieb John Goerzen: >>>> Package: systemd >>>> Version: 215-5+b1 >>>> Severity: grave >>>> Justification: renders package unusable >>>> >>>> On investigating why my 8GB system, which was suddenly running extremely >>>> slow and maxed out on swap, I discovered numerous systemd-logind >>>> processes hogging RAM. Specifically, 41 processes using 4278148KB (or >>>> roughly 4GB) of RAM. >>>> >>>> Here is some output from top: >>>> >>> As John told me on IRC: He is running systemd-logind under systemd-shim >>> on this particular system. >>> On other systems, where systemd is PID 1 he does not experience this >> issue. >>> I told him to find out the current running systemd-logind process which >>> owns the org.freedesktop.login1 D-Bus name via >>> "dbus-send --system --dest=org.freedesktop.DBus --print-reply >>> /org/freedesktop/DBus org.freedesktop.DBus.GetConnectionUnixProcessID >>> string:org.freedesktop.login1" >>> >>> and monitor that process via strace while periodically checking with the >>> above command, when logind drops off the bus. So we can eventually see >>> from the strace what happens at that time. >>> >>> Unfortunately, when stracing the process, John is no longer able to >>> reproduce the issue, as he told on IRC. >>> >>> John, to narrow down the problem, could you please boot with >>> init=/bin/systemd to verify if this issue is indeed related to >> systemd-shim. >> -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
