[Expired for systemd (Ubuntu) because there has been no activity for 60
days.]
** Changed in: systemd (Ubuntu)
Status: Incomplete => Expired
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
The morning copy ran without incident but the evening copy triggered a
fault between 1944 and 1952 CST (UTC-5). I'm attaching a TAR which
contains three screenshots (before, during, and just after the fault) as
well as the time-relevant output of 'journalctl', and an sosreport. The
sosreport
Starting today I will be running the copy next to an htop window ready
to capture screenshots (before, during, and after failure). The first
run today did not fail. I used a variation of your script to copy the
source file multiple times to different file names, in the hope that
taking my main
Hi Daniel,
Finally, I tried to reproduce your scenario on my side but not able to
reproduce.
* Environment:
ubuntu 22.04
64G RAM (allocated a process to occupy 32G RAN)
NVMe storage
32G micron SD card (dd /dev/random to a 29G file)
* A script to reproduce:
#!/bin/bash
count=0
file="29G-file"
Yesterday's copies did not trigger systemd-oomd, but one of them did
cause systemd-journald to timeout and restart.
Oct 16 14:00:07 Boromir systemd[1]: systemd-journald.service: Watchdog timeout
(limit 3min)!
Oct 16 14:00:07 Boromir systemd[1]: systemd-journald.service: Killing process
578
1. "ionice -c3 nice cp -a SRC DST" is mandatory? Does it reproducible through a
normal "cp -a"?
A: Unknown. I've been using that out of habit for years to retain as much
responsiveness as possible. For future copies I'll use just 'cp -a'.
2. What's the fail rate?
A: Over the last two weeks I
It's interesting.
I would like to reproduce your scenario on my side.
Would you please share:
1. "ionice -c3 nice cp -a SRC DST" is mandatory? Does it reproducible through a
normal "cp -a"?
2. What's the fail rate?
3. Would you please share the data type from "SRC"? a single large 29,613MB
I've had two more instances, one on the 18th and one (multiple,
actually) today. Both were triggered by copying a file as I'd described
(from CLI, "ionice -c3 nice cp -a SRC DST"). Today's OOM events also
killed a Firefox window for some reason. I captured an sosreport on
both days, but last
Embarrassingly it seems that this week I'm getting more proper behavior.
I will keep trying to replicate here as time permits, but the system
applied some updates automatically and I also installed a few things
since the first incident (sane, wireshark, etc). Rolling everything
back isn't much of
** Changed in: systemd (Ubuntu)
Status: Invalid => Incomplete
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1985887
Title:
systemd kills gnome-shell or
Hi Daniel,
could you please share the log (e.g. apport, sosreport or journalctl
when issue happens)?
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1985887
Title:
I have a 'normal use case' that triggers this: Copying a large file. My
system has 32GB of RAM and 4GB of swap. Trying to copy a 29,613MB file
from a reasonably fast SD card to my local (cacheless) NVMe SSD is
triggering systemd-oomd.
--
You received this bug notification because you are a
Closed it first because I can not find any normal use case as what stress-ng
did.
Feel free to reopen and investigating if any normal use case got "being ...% >
50.00% for > 20s with reclaim activity".
** Changed in: systemd (Ubuntu)
Status: New => Invalid
** Changed in: oem-priority
alright, although the children are belong to same cgroup but
> as a measurement of the CPU time lost due to lack of memory.
it seems to me there is no a normal case from users will hit it unless
memory stressors.
--
You received this bug notification because you are a member of Ubuntu
Touch
yes, it same as what I understand.
systemd-run and over ssh could have a session out of monitored by systemd-oomd.
I'm trying to understand if any use cases will similar to this case?
something like launching a lot of tabs from chrome/firefox browsers, I suppose
all tabs will belong to same
It seems that systemd-oomd is doing what it is supposed to do -- you're
running a memory stress test that is exceeding the memory pressure
limits set by systemd-oomd, so it is killing the offending cgroup(s). If
you want to run the stress tests in a separate cgroup, try making a
script called e.g.
systemd-oomd doesn't care about the slices other than user slice, it's
why the sshd won't be killed but it also use a lot of memory:
/sys/fs/cgroup/user.slice/user-1001.slice/session-4.scope/memory.pressure
some avg10=69.94 avg60=69.56 avg300=43.64 total=202010660
full avg10=69.07 avg60=68.73
okay, I can reproduce this issue in Xorg as well.
`stress-ng --stack 0 --timeout 300` and I can see
Tue Aug 16 03:13:49 PM CST 2022
./memory.pressure
some avg10=64.25 avg60=28.75 avg300=7.33 total=23575913
full avg10=62.74 avg60=28.13 avg300=7.17 total=23107632
18 matches
Mail list logo
