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 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. 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. _______________________________________________ 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
