From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 5DB01138350 for ; Fri, 1 May 2020 16:34:56 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id E9323E0B4E; Fri, 1 May 2020 16:34:50 +0000 (UTC) Received: from mail-ot1-x344.google.com (mail-ot1-x344.google.com [IPv6:2607:f8b0:4864:20::344]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 94E6EE0AC8 for ; Fri, 1 May 2020 16:34:50 +0000 (UTC) Received: by mail-ot1-x344.google.com with SMTP id m13so2986550otf.6 for ; Fri, 01 May 2020 09:34:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:openpgp:autocrypt:message-id:date :user-agent:mime-version:in-reply-to; bh=bU3tSB8HnG7itczTX5VwpA1Dv4sLyE7FaUfIzOmChqE=; b=r6raUX8HjDoj9yHHdUJdqqgllhgYxUpwhsupBnaPHIr8o9tNQBuHx2lpJ47CpKS3Bk 0N+m0iQmBr8an3tg7pM8g4ZsX6nU81g9wi4zkNc4MljtBJmM9VxXS0UqzQ99ESGYqhqW BMNr0K6Kx+fiTwuI3NCSrsz7yA3xYN3/f+WKtbn3uLMIWPsNCM/N8HgBkMCjXE9WIvrP IxcEpxMW/98CNdh/WVgIhzbDUKfV4XoDTlSAh9PMljP/dZx71S6qBEQOLUS7sE2ncZt0 Brg+K4RC2TBT3knl2BRGhcW9eY1rWgbGz8au6nEp/FKL5kovS3KVvl4SNONbN5sxxkdp 9AEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to; bh=bU3tSB8HnG7itczTX5VwpA1Dv4sLyE7FaUfIzOmChqE=; b=Qov2LcLWBXOcCi4kgYPZAbJOIlN8lZahimisJbGMT9Nbw4fGtzZj50EraGSn/T9hSc dUauEX7J4bML5uy+CMCT42NRpRM36wUiXfbgdmzJQPOZa36jiEITQLEtqij5yOFgso68 6qPYy3eX2awtsYYPOGT+SAuJjyy1wG08NxH++isFdivsjkUYV/H7I7R7ZzVHSx0HFss+ 8CpPXFf4IHPzgWDjPBLy1D+Ka78qQBft/JhfWxSozcVBezn/GwJk593cWKqahR4Lo/j5 pX00P/LOetOm3YzyQ3J3mGghXRG99tTHJy4HPnSGD6GYY7nWP1s6VoulaW0XwVfE0HMh rR8Q== X-Gm-Message-State: AGi0PuaO5sfxxQCkhvZogXdB+cDTU8ZWFEwKjWrET9UpZ+9Fyk2hreDN sfEUKA5+wmwS2uyi0h1NVwblL4WG X-Google-Smtp-Source: APiQypJndNnEaPE6KtcxqI5ymmNHyObKMUXEBlf9lzZhBWHer+ija791ZATrDaY65cIt4JsN1uErwg== X-Received: by 2002:a05:6830:1e4e:: with SMTP id e14mr4190783otj.91.1588350889770; Fri, 01 May 2020 09:34:49 -0700 (PDT) Received: from [192.168.0.100] (adsl-074-188-249-136.sip.asm.bellsouth.net. [74.188.249.136]) by smtp.gmail.com with ESMTPSA id d61sm925467otb.58.2020.05.01.09.34.47 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 01 May 2020 09:34:49 -0700 (PDT) Subject: Re: [gentoo-user] sddm-helper and high memory usage To: gentoo-user@lists.gentoo.org References: <706b68ae-a6d7-db97-33e2-98838682befc@gmail.com> <8590358.CDJkKcVGEf@lenovo.localdomain> From: Dale Openpgp: preference=signencrypt Autocrypt: addr=rdalek1967@gmail.com; prefer-encrypt=mutual; keydata= mQINBFxc7MgBEAC+zrgEdqJJiDe/UDAB+ScmferXWfJTVjbVT2T4DQ7jiLrgP9aNUo1HioNF mrU3JPOCR32gvZyTbY1+niO5+VSo/+pSqQ785h6ZDj1klMkrg6tEzGnf2MNBpBj4houZwxQ+ WDKKTg2M9F+lv8wTIdR/JQn+hSviktLMtrghQlyLhpapsLXWLA6gMFebpQYwxUwemvan8ddX lQvJe9FGyFYvBi0dp1gl10F2O+DVZJxvX8xkX+yImVlhVJiC31gXHRcj+Qlo7gprlU7TIieF Uow6/ZvYKJ26pztVdFCg5w0rMJkF/x8Zd4A6wnuptiAPmWaQ1+YKgYDonbDUgwqFSx5/lN5z DGZ4LlioxeUTTPVvZsqBIeDz6jNFA583OYbo1/S26dqrvTFf2DKlsvoDpVfAhNlwJPjoixs0 X3FNqPv+M10n4kq5Iz7Q9E3O4s/nfFIYGocEslVka7zZPkXSaHbsn+KJlY8XV6qxtCEdh0/V XX1+1aU2J74M0JikWhpwxTZ1dP5aOyWSPPEgFFIRW6xwwC02SoRH9a7mggfGYp/YjPlONNaT SCL8sgRfvmq3D0XTbLyTjSbExxkfKDmbePQagawDE3TlI/oivHf1JaAcbwMb3LZuU4TGcOIl 5D+x7q0MUIeCop0ZFOwAnqW3AVVNvsBkv2KN+IHJryWAf0/iMQARAQABtBtEYWxlIDxyZGFs ZWsxOTY3QGdtYWlsLmNvbT6JAk4EEwEIADgWIQTZ7suruPBaS60bCYXvEM/XWu+ZnAUCXFzs yAIbIwULCQgHAgYVCgkICwIEFgIDAQIeAQIXgAAKCRDvEM/XWu+ZnN+7D/4/1dNG4aCz0+v+ 0dcjV5tY1feYEWCdHKyDzxWBxlCpd/0NPRQeNY4VMjbCl/sq7GkXi/c2SbfWDQ5BQRkkExG1 pSwuXSIehGok/4fpTi3HDAguRvzdCqlKPt7me05FyiC/WnpY5GOlJ3ruGw2qABv/RmV2q5b/ tkq7h1y1f16DTNr3/nsj8HzHcrHdXdL4kaYChSOe/dbQR9Stqak7eMyR+iwvrJMNF/CGl70P 2x5ybsXMDzRVOqNcpa5ZdhEMTVh6+vC1SOmm1BFMF8XCqBEvBbcHWDQmGYTdNCsS/ADm8CBl gvjJgLdIsAzoMu4WHQDFnzXAoArqFWgAf53isOS4AWrv29tF9b8Aa1vb7h5JEa+ArcMsA6Gl X38+GY6WXXaxKI9n3PTCWu9tPGnRh7mABjnwEosDDqmzw8aTAYECb3avDuGY2rmcjgh4H6RE w08d63j1T4d5J9wlm4TGtW/VHgbUFkATEdH3Acl/EjFiyqTiX7p8kU6Reu5enIkogA93xoQh Rmy7ZiST/5LN+ZkaOdyjIw0L+5KalslN9SKt809YxgJ6kPo657LNTFPiFvFA46/SEWcBYrzq Xk0wEW0gBRWf+BqN0qRhU0/EQ+QfRdLLFg2xtUePwlheYLXxfyDLrdCCOLWYpkzbjCZHLS4u 69smbvR9S9KBDNzJybxEWrkCDQRcXOzIARAA5IGRWTqaM44IJgBYghZg2fGj0Am7KWPhE7V7 T/EEe7vVSUEFqHtlHzI4ZK6Q0AZ9uAEjE8IJIQ7KoTjzNqAtabP0vp3s0szgtJlsZ+8vGKlQ my7fvzSrdoQL0Xn7CEwJYFXJ1EMUcYIQeoHG1cUAaXx73k9BFbjwjnUeMrqlV/ZovQlg7duW nESfQ7HZu5NrtYyY3jPMUouxiO9WQPh+IHxZbt1absF2VcvRAymD32RxGvMPbw6ChMRD/p9O 4PH7M5rXaxr78NXQX9E48vrI00f1cYb9NSN1HnSV8cW3jKObVjdBk6jPQwrMvdpgdQhUB9aZ HS/9mC9mmAgiXKyCpzXe7FPB6QznSfn4GIaC/luy1e6SLUkJhRK/niB+gq+Mfxg2zXNuDUTI cMGmpDCp3kgUoorkaltk8RW09io95BkXrGhcDNuSGZfAParBc7RXyYpbIcax8St7tEAd2oFh 4seYOPUlzuhGrPpqR/91wrFc4E1260GKauSr4UhMJv6tygBwyC0mmBMKi+ZXw6ZdZxA5fg7y 35P3TILjznCXXTDgRHq9A3NknKRMcgFacX6eIhANkMFo6oJVjuEgy1dvu1wFfDq7c+i8GAHu L4pYzyXYu6PporlNNU0xSwdVgzM/uuK0lt+UxCimgC+YR3IezgDcbfudb7h9dGIwL+bbPL0A EQEAAYkCNgQYAQgAIBYhBNnuy6u48FpLrRsJhe8Qz9da75mcBQJcXOzIAhsMAAoJEO8Qz9da 75mcXZ4P/1YXgWDZek7mhzrf6uaQzMxa92P89HeWz4PlgB/32symeEFAV04WazzBZffI8AYY rGA1Xmu/2VaB9+FOODyKhUWBc2UL0NRWBk6POwboyTdKlclmpixaN9zLcBt0YLejoRfN1B/5 aQf9/lUDZMnAiCyz0FgeqEMUshldmwWC35RqnjrCbbuk2vIqSH6BLDIXU6jQrLHE1DF0ai41 wLtQFAFXPhn45n0ZwYhVs4Z32z4sjXrIvgBgCaXa4HM+L1Klne0KiNM8ReFTTpTE0SgyDOSZ O3MOa2n77i6JbVtsbiFYnNeP3J9S/l3jevGpZEtNQOKrIm1MW8jGuHWtsDeMkT/mCcSodlkt PxIo+mMK9GpGvG2hW80LiohqNfUbNwAmr3blOYY4URPXPRnEnPs4pmTmL5owjw2dkg145i9I D42Tq+XZ6YtWt3SGzGbAYow6XwTwZ5NFAzV9UQuCGrDw4KWan6O6Z+VIYWsn0UMZlu1Obxna aocofkaUCbISK26kImuD1aA8juSHC18Qv1xUage6/UakbSxyDtACqt6hOVFKX3IA59ApdNRT +2x3iCmlvF9MJsGgFq6IpqL+Fk7iWV8Kjbz0wQOId6N9+JdQh3LrLaS7a1PowUm1z9DK5/O0 Yg+gpDnEOOFI7WM5u7a7FSM2Z/LXGVwel/0eWvLk9tN6 Message-ID: <8c351adf-febd-f84a-2bec-47825055fb85@gmail.com> Date: Fri, 1 May 2020 11:34:45 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0 SeaMonkey/2.53.1 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 In-Reply-To: <8590358.CDJkKcVGEf@lenovo.localdomain> Content-Type: multipart/alternative; boundary="------------B4194FD70E56011AC3322F68" X-Archives-Salt: 0187660e-eb83-4f53-a72c-fcbb40193e48 X-Archives-Hash: 4a2cb7c4d0775c865a45b5b0c87db60e This is a multi-part message in MIME format. --------------B4194FD70E56011AC3322F68 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Michael wrote: > On Thursday, 30 April 2020 21:14:05 BST Dale wrote: >> Dale wrote: >>> Howdy, >>> >>> <<>> >>> When it did this the other day, I closed all my programs so I could >>> logout, reset and log back in again. After I hit logout, I noticed the >>> little memory usage meter on the bottom of my screen was down to a more >>> normal level. It was already logging me out so to late to stop it. It >>> seems that it dropped after I closed Firefox. I tend to have two >>> profiles running and they use quite a bit of memory on their own. The >>> new thing is sddm using this much as well. Could Firefox have some >>> effect on this?? >>> >>> <<>> >>> Any ideas? >>> >>> Dale >>> >>> :-) :-) >> Ignore the part about Firefox. I noticed it was up to about 4.3GBs or >> 13.5% again and closed all my browsers. After that was done and it >> settled a bit, it was using the same amount of memory. Closing my >> browsers has no effect on it's memory usage. Logging out and back in >> again, back to normal. I'm sure it will start rising again tho. >> >> Still curious to see if anyone else has this issue or has a idea on how >> to fix it. >> >> Thanks. >> >> Dale >> >> :-) :-) > I'm running stable here and have not noticed sddm eating up much memory on a > single user PC with 16G RAM. I'm not running FF at this moment, but Kmail, > plus a tonne of akonadi sql processes, plus gkrellms. However, sddm shouldn't > be consuming much RAM beyond passing authentication credentials to X and > starting a session, dynamically pulling in dbus & syslog. > > My sddm config has not been changed from defaults, but I have switched the > theme to Elarun via Plasma's SystemSettings. I use no icon for avatar. The X > session memory usage changes, but sddm is pretty much stable from what I > observed. > > USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND > root 3822 0.0 0.0 136480 15324 ? Ssl 15:37 0:00 /usr/bin/sddm > root 3888 4.1 0.5 1384204 85148 tty7 Ssl+ 15:37 1:42 /usr/bin/X - > nolisten tcp -auth /var/run/sddm/{long_string_here} -background none -noreset > -displayfd 17 -seat seat0 vt7 > sddm 3961 0.0 0.0 4552 2264 ? S 15:37 0:00 dbus-launch > --autolaunch long_string_here --binary-syntax --close-stderr > sddm 3962 0.0 0.0 3868 1948 ? Ss 15:37 0:00 /usr/bin/ > dbus-daemon --syslog-only --fork --print-pid 5 --print-address 7 --session > root 4030 0.0 0.0 54516 14020 ? S 15:38 0:00 /usr/libexec/ > sddm-helper --socket /tmp/sddm-auth0472070a-360a-4d6f-9715-b06b8f18b464 --id 1 > --start /usr/bin/startplasma-x11 --user michael > michael 10000 0.0 0.0 7964 752 pts/1 S+ 16:18 0:00 /bin/grep -E > --colour=auto --color=auto USER|sddm > What you post is about what it used to do.  Last night I rebuilt everything equery d sddm returned plus a couple extra packages as well.  I logged out, logged back in and while better, it is still using to much memory.  This is the current usage and it has been steady for a few hours now. USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND root     20325  0.2  1.2 458860 418280 ?       S    05:20   0:53 /usr/libexec/sddm-helper --socket /tmp/sddm-auth09e6b5a4-8a3d-42d5-9068-eefeecc22458 --id 1 --start /usr/bin/startplasma-x11 --user dale While it is better, it should be a lot less than that.  I have 32GBs here so even 1.2% is a good bit.  I'm starting to run revdep-rebuild as I type.  I'll see if it catches anything.  If not and it keeps doing this, I may do a emerge -e world which should catch any sort of linking/depends problems.  I wonder if this has anything to do with my wallpapers??  That caused other issues a while back but surely not.  Thanks for the info.  At least it seems to just be me.  Dale :-)  :-)  --------------B4194FD70E56011AC3322F68 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
Michael wrote:
On Thursday, 30 April 2020 21:14:05 BST Dale wrote:

Dale wrote:

Howdy,

<<<SNIP>>>
When it did this the other day, I closed all my programs so I could
logout, reset and log back in again.  After I hit logout, I noticed the
little memory usage meter on the bottom of my screen was down to a more
normal level.  It was already logging me out so to late to stop it.  It
seems that it dropped after I closed Firefox.  I tend to have two
profiles running and they use quite a bit of memory on their own.  The
new thing is sddm using this much as well.  Could Firefox have some
effect on this??

<<<SNIP>>>
Any ideas? 

Dale

:-)  :-) 

Ignore the part about Firefox.  I noticed it was up to about 4.3GBs or
13.5% again and closed all my browsers.  After that was done and it
settled a bit, it was using the same amount of memory.  Closing my
browsers has no effect on it's memory usage.  Logging out and back in
again, back to normal.  I'm sure it will start rising again tho.

Still curious to see if anyone else has this issue or has a idea on how
to fix it. 

Thanks.

Dale

:-)  :-) 

I'm running stable here and have not noticed sddm eating up much memory on a 
single user PC with 16G RAM.  I'm not running FF at this moment, but Kmail, 
plus a tonne of akonadi sql processes, plus gkrellms.  However, sddm shouldn't 
be consuming much RAM beyond passing authentication credentials to X and 
starting a session, dynamically pulling in dbus & syslog.

My sddm config has not been changed from defaults, but I have switched the 
theme to Elarun via Plasma's SystemSettings.  I use no icon for avatar.  The X 
session memory usage changes, but sddm is pretty much stable from what I 
observed.

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root      3822  0.0  0.0 136480 15324 ?        Ssl  15:37   0:00 /usr/bin/sddm
root      3888  4.1  0.5 1384204 85148 tty7    Ssl+ 15:37   1:42 /usr/bin/X -
nolisten tcp -auth /var/run/sddm/{long_string_here} -background none -noreset 
-displayfd 17 -seat seat0 vt7
sddm      3961  0.0  0.0   4552  2264 ?        S    15:37   0:00 dbus-launch 
--autolaunch long_string_here --binary-syntax --close-stderr
sddm      3962  0.0  0.0   3868  1948 ?        Ss   15:37   0:00 /usr/bin/
dbus-daemon --syslog-only --fork --print-pid 5 --print-address 7 --session
root      4030  0.0  0.0  54516 14020 ?        S    15:38   0:00 /usr/libexec/
sddm-helper --socket /tmp/sddm-auth0472070a-360a-4d6f-9715-b06b8f18b464 --id 1 
--start /usr/bin/startplasma-x11 --user michael
michael  10000  0.0  0.0   7964   752 pts/1    S+   16:18   0:00 /bin/grep -E 
--colour=auto --color=auto USER|sddm


What you post is about what it used to do.  Last night I rebuilt everything equery d sddm returned plus a couple extra packages as well.  I logged out, logged back in and while better, it is still using to much memory.  This is the current usage and it has been steady for a few hours now.


USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root     20325  0.2  1.2 458860 418280 ?       S    05:20   0:53 /usr/libexec/sddm-helper --socket /tmp/sddm-auth09e6b5a4-8a3d-42d5-9068-eefeecc22458 --id 1 --start /usr/bin/startplasma-x11 --user dale


While it is better, it should be a lot less than that.  I have 32GBs here so even 1.2% is a good bit.  I'm starting to run revdep-rebuild as I type.  I'll see if it catches anything.  If not and it keeps doing this, I may do a emerge -e world which should catch any sort of linking/depends problems. 

I wonder if this has anything to do with my wallpapers??  That caused other issues a while back but surely not. 

Thanks for the info.  At least it seems to just be me. 

Dale

:-)  :-) 
--------------B4194FD70E56011AC3322F68--