On Sun, 12 Mar 2023 13:37:46 -0000 "Andre Robatino" <robatino@xxxxxxxxxxxxxxxxx> 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. _______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
