On Sun, 12 Mar 2023 15:47:48 -0000 "Andre Robatino" <robatino@xxxxxxxxxxxxxxxxx> wrote: > Does your machine have 4GB or less of RAM? If you have more, it may > be much less likely to trigger. I just verified that when I log into Yeah, 16 GB. > GNOME on the machine in question, an rsync of a single large file > that never works when done remotely works fine, it only fails when > attempted from a non-DE login (ssh or console). This should be easy > to reproduce with a VM with 1 or 2 GB of RAM (I don't know what the > current minimum is). I have a F38 VM that I normally allocate 2GB and > boot in multiuser, just to update. I was starting to notice the > problem in that as well, so at first I increased the RAM to 4GB and > didn't notice it anymore. I don't know why the VM requires less RAM > than the F37 bare metal machine. Anyway, once I suspected that the > problem was with the non-DE login, I lowered the allocation to 2GB > and booted in graphical, and logged into GNOME, and the problem was > gone. I don't like doing that, though, since the updating takes > longer with all the nonessential stuff going on in GNOME (which is > why I normally use multiuser). The VM is running on a different host > with 16GB so I doubt this has anything to do with hardware issues. This sounds like a bug, as if systemd-oomd is imposing much stricter standards when login is sshd or console. I agree with you, how can a resource intensive task like a desktop succeed when a minimal implementation fails? I think the current minimum memory is 2GB (I vaguely recall that I recently read on the test(?) list that people in some situations are having issues with that amount). Like you, I notice that dnf is using almost no memory when I do updates from multiuser. Maybe systemd-oomd is somehow interpreting that usage incorrectly? > I did try "systemctl mask systemd-oomd" yesterday, but then > discovered that if I reinstall systemd-oomd-defaults, it starts > running again, even though it's still masked, so that's not reliable. > The same thing would probably happen on any systemd update, unless I > just removed systemd-oomd-defaults itself. That hasn't happened to me. When I check with systemctl -a -t service it is still masked, and the status of systemd-oomd is failed, dead. And that is after updates to systemd. But I don't have the package systemd-oomd-defaults installed. Reinstalling that seems like it might be a reset of the mask to the default. Or maybe, if that is the package that actually sets up OOMD, I don't even have OOMD installed. That would explain why my experience is different. _______________________________________________ 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
