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.