I filed https://bugzilla.redhat.com/show_bug.cgi?id=2177722 for my original
problem (involving non-DE logins) and it was indeed fixed with the latest
systemd updates in both F37 and F38. I know other people have reported it
happening in GNOME but have never seen it personally. There are closed b
On Sun, 12 Mar 2023 13:37:46 -, Andre Robatino wrote:
> I have 3 machines with clean F37 installs.
Dunno yet whether it's also F37 or just F38, but here on F38 even
gnome-terminal is getting killed when running a simple tar command in it
that works on creating a ~20 GB archive.
__
Thanks. I confirmed on the affected machine that immediately after removing
systemd-oomd-defaults, it was still monitoring the same CGroups, but after
rebooting, it was monitoring none, even though systemd-oomd was still enabled
and running.
___
users
Hi.
On Sun, 12 Mar 2023 17:33:42 + "Andre Robatino" wrote:
> I just tried removing systemd-oomd-defaults and it's still possible to run
> systemd-oomd so I was wrong in thinking that would prevent it.
Right: systemd-oomd-defaults only configures systemd-oomd.
rpm -ql --scripts systemd-
I've heard that, but for me, with limited RAM, both DNF transactions and an
rsync of a very large file fail in multiuser (by causing logout while they're
running) while they both succeed in GNOME on the same machine.
___
users mailing list -- users@list
Andre Robatino composed on 2023-03-12 15:58 (UTC):
> BTW, I did notice that the problem was gone during the time that systemd-oomd
> wasn't running, so that's definitely the cause. Unfortunately, the mask
> command alone isn't enough to prevent it from running, I'd have to either
> remove syste
I just tried removing systemd-oomd-defaults and it's still possible to run
systemd-oomd so I was wrong in thinking that would prevent it.
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproj
On Sun, Mar 12, 2023 at 9:38 AM Andre Robatino
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
>
On Sun, 12 Mar 2023 15:47:48 -
"Andre Robatino" 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 w
I've heard dnf uses a lot of memory, but in my 2GB F38 VM, I can run a large
DNF transaction with no problem when logged into GNOME. On 4GB F37 bare metal,
in multiuser, even updating one letter at a time isn't enough, even "dnf check"
can fail. I read somewhere that GNOME and KDE are the only t
> On 12 Mar 2023, at 15:58, Andre Robatino wrote:
>
> BTW, I did notice that the problem was gone during the time that
> systemd-oomd wasn't running, so that's definitely the cause. Unfortunately,
> the mask command alone isn't enough to prevent it from running, I'd have to
> either remove
BTW, I did notice that the problem was gone during the time that systemd-oomd
wasn't running, so that's definitely the cause. Unfortunately, the mask command
alone isn't enough to prevent it from running, I'd have to either remove
systemd-oomd-defaults or edit some config files. And this really
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 lo
On Sun, 12 Mar 2023 13:37:46 -
"Andre Robatino" 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
It's not just ssh. It happens even if I boot in multiuser and log in via the
console, so any non-DE login is affected. Sometimes, I can't even run a simple
"dnf check" command (after having a previous transaction aborted by a logout)
without being logged out again. And the free command indicates
On Sun, Mar 12, 2023 at 10:38 AM Andre Robatino
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 dif
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
17 matches
Mail list logo
