On Sun, 12 Mar 2023 15:47:48 -0000
"Andre Robatino" <robatino(a)fedoraproject.org> 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.