On Sun, 12 Mar 2023 13:37:46 -0000
"Andre Robatino" <robatino(a)fedoraproject.org> wrote:
I have 3 machines with clean F37 installs. One of the F37 machines
has 4GB of RAM, and I maintain it as a backup and normally only log
in via ssh and do dnf updates via command line. In the last few weeks
this has become extremely difficult to do due to being automatically
logged out, presumably by systemd-oomd. It happens even if I boot in
multiuser, which ought to reduce memory use. From what little I've
read and what experimentation I've done so far, it appears that being
logged into a DE (maybe only GNOME or KDE?) protects against this,
but non-DE logins (including ssh), and any commands running in them,
are not protected. This goes against the expectation that non-DE
access should be LESS likely to run out of memory, especially if
there isn't even a DE running. How hard would it be for systemd-oomd
to be configured to protect non-DE logins and anything running in
them?
I've also read that configuring non-zram swap might be a cure. As I
said, these are clean F37 installs, and if that's necessary for
reasonable behavior when there's not enough RAM, the installer should
be doing it automatically. In my case, I don't think that's the
cause, since the free command suggests that I'm only using a fraction
of both the memory and swap even when the automatic logging out is
happening.
I don't have any problems with any of the things that you do of F37,
and I also initially log in to multiuser. This sounds like there is
some configuration issue on your system causing a problem. Or could
the memory be failing with intermittent faults? Or maybe you have a
setting that create the problems (seems like a longshot if you are
using a default install). If you can find a cause, it would be good to
let the maintainers of systemd-oomd know with a bugzilla.
You could, as root, run
systemctl stop systemd-oomd.service
If there is in fact an OOM condition, your system will hang. But, as
George said, it might be better to run one of the tops in a terminal,
and see what is happening with memory (top, or htop, or itop). Or
dmesg
or
journalctl -r
I took the additional step of running
systemctl mask systemd-oomd.service
so that it never will run. I have never had an issue, though I do have
disk based swap, so when I get close to memory issues (around 90%
usage), I notice the slowdown or hear the disk activating a lot.