Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal
by Ben Cotton
https://fedoraproject.org/wiki/Changes/KDEEarlyOOM
== Summary ==
As [[Changes/EnableEarlyoom|Fedora Workstation did in F32]], install
earlyoom package, and enable it by default. If both RAM and swap go below
10% free, earlyoom issues SIGTERM to the process with the largest
oom_score. If both RAM and swap go below 5% free, earlyoom issues SIGKILL
to the process with the largest oom_score. The idea is to recover from out
of memory situations sooner, rather than the typical complete system hang
in which the user has no other choice but to force power off.
== Owner ==
* Name: [[User:bcotton|Ben Cotton]]
* Email: bcotton(a)redhat.com
== Detailed Description ==
Shamelessly copied from Workstation, which did it in the last release:
Certain workloads have heavy memory demands, quickly consume all of RAM,
and start to heavily page out to swap. (Heavy paging, is often called "swap
thrashing" for added descriptive effect, probably because it's noticeable
and annoying). Incidental swap usage is a good thing, it frees up memory
for active pages used by a process. Heavy swap usage quickly leads to a
very negative UX, because it's slow, even on modern SSDs. Due to installer
defaults, the swap partition is made the same size as available memory (at
install time), which can be huge. This just extends swap thrashing time.
On the one hand, we want this resource hungry job to complete. On the other
hand, we want our system to be responsive while that other work is going
on. But once the GUI stutters or even comes to an apparent stand still
(hang), we're really wishing the kernel oom-killer would kick in and free
up memory, so we can start over (maybe using memory or thread limiting
options - which arguably should be more intelligently figured out, and that
too is a work in progress but beyond the scope of this feature).
However, once in a heavy swap scenario, it's relatively common the system
gets stuck in it, where GUI interactivity is terrible to non-existent, and
also the kernel oom-killer doesn't trigger. From a certain point of view,
this is working as intended. The kernel oom-killer is concerned about
keeping the kernel running. It's not at all concerned about user space
responsiveness.
Instead of the system becoming completely unresponsive for tens of minutes,
hours or days, this feature expects that an offending process (determined
by oom_score, same as the kernel oom-killer) will be killed off within
seconds or a few minutes.
== Benefit to Fedora ==
KDE users will be able to take advantage of the benefits Workstation users
got from enabling earlyOOM in Fedora 32:
* improved user experience by more quickly regaining control over one's
system, rather than having to force power off in low-memory situations
where there's aggressive swapping. Once a system becomes unresponsive, it's
completely reasonable for the user to assume the system is lost, but that
includes high potential for data loss.
* reducing forced poweroff as the main work around will increase data
collection, improving understanding of low memory situations and how to
handle them better
* earlyoom first sends SIGTERM to the chosen process, so it has a chance of
a proper shutdown, unlike the kernel's oom-killer
== Scope ==
* Proposal owners:
** Modify {{code|
https://pagure.io/fedora-comps/blob/master/f/comps-f33.xml.in}} to include
earlyoom package for in {{code|kde-desktop}} section.
** Add {{code|
https://src.fedoraproject.org/rpms/fedora-release/blob/master/f/80-kde.pr...
to include:
<pre>
# enable earlyoom by default on KDE
enable earlyoom.service
</pre>
* Other developers: None, unless KDE-based Spins/Labs want to opt out
* Release engineering: N/A
* Policies and guidelines: N/A
* Trademark approval: N/A
== Upgrade/compatibility impact ==
earlyoom.service will be enabled on upgrade. An upgraded system should
exhibit the same behaviors as a newly-installed system.
== How To Test ==
* Fedora 31/32 KDE users can test today:
** {{code|sudo dnf install earlyoom}}
** {{code|sudo systemctl enable --now earlyoom}}
And then attempt to cause an out of memory situation. Examples:
** {{code|tail /dev/zero}}
** https://lkml.org/lkml/2019/8/4/15
== User Experience ==
earlyoom sends SIGTERM to processes based on oom_score when both memory and
swap have less than 10% free and SIGKILL when below 5%.
== Dependencies ==
None
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?) Owner reverts
changes
* Contingency deadline: Final freeze
* Blocks release? No
== Documentation ==
* {{code|man earlyoom}}
* https://github.com/rfjakob/earlyoom
* https://www.kernel.org/doc/gorman/html/understand/understand016.html
== Release Notes ==
The earlyoom service is now enabled by default in Fedora KDE.
The earlyoom service monitors system memory usage. If free memory falls
below a set limit, earlyoom terminates an appropriate process to free up
memory. As a result, the system does not become unresponsive for long
periods of time in low-memory situations.
The following is the default earlyoom configuration:
* If both RAM and swap go below 10% free, earlyoom sends the SIGTERM signal
to the process with the largest oom_score.
* If both RAM and swap go below 5% free, earlyoom sends the SIGKILL signal
to the process with the largest oom_score.
For more information, see the earlyoom man page.
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
3 years, 6 months
Searching a new home for my packages
by Thomas Spura
Hi all,
unfortunately, I don't find much time anymore to look for my packages ..
Due to that, I would like to step down as the primary maintainer and
am searching for a new home for my packages!
On most of them, I am co-maintainer and the following are the ones, where I
am maintainer (and hope I didn't forget one, if so, please let me know):
- python-jupyter-client
- python-jupyter-core
- python-matplotlib
- python-tornado
- ipython
- mpi4py
- php-zmq
- pynac
Feel free to let me know, if you are interested in taking any of those
packages.
Best,
Thomas
--
Fedora: https://fedoraproject.org/wiki/User:Tomspur
3 years, 6 months
NetworkManager keyfile instead of ifcfg-rh - Fedora 33 System-Wide
Change proposal
by Ben Cotton
https://fedoraproject.org/wiki/Changes/NetworkManager_keyfile_instead_of_...
== Summary ==
Change the default settings plugin of NetworkManager so that new
profiles will be created in keyfile format instead of ifcfg-rh format.
== Owner ==
* Name: [[User:Thaller| Thomas Haller]]
* Email: <thaller(a)redhat.com>
== Detailed Description ==
NetworkManager supports settings plugins to persist connection
profiles to disk. There is the native ''keyfile'' format and the
Fedora/RHEL specific ''ifcfg-rh'' format originally from initscripts.
The keyfile plugin is always enabled in NetworkManager and can handle
any supported type of profile. It stores profiles under
`/{etc,usr/lib,run}/NetworkManager/system-connections` and is
documented in [https://developer.gnome.org/NetworkManager/stable/nm-settings-keyfile.html
nm-settings-keyfile manual]. The ifcfg-rh format is in part compatible
with the network-scripts package from initscripts, however both
network-scripts and NetworkManager define their own extensions
([https://developer.gnome.org/NetworkManager/stable/nm-settings-ifcfg-rh.html
[1]]). Since network-scripts and NetworkManager are fundamentally
different, the same ifcfg file is not treated exactly the same by both
systems. In the past, having the ifcfg-rh format made it easier for
users familiar with initscripts to migrate to/from NetworkManager.
The settings plugins are configurable in
[https://developer.gnome.org/NetworkManager/stable/NetworkManager.conf.html
NetworkManager.conf] via the `"main.plugins"` option. Multiple plugins
can be configured and on Fedora 32 and older, the compile time default
for the option is `"ifcfg-rh,keyfile"`. This means, that when
NetworkManager stores a new profile to disk, it will first try to
persist it in ifcfg-rh format before falling back to keyfile format,
if the ifcfg-rh plugin doesn't support the profile type. When reading
profiles from disk, NetworkManager will read and expose profiles from
both settings plugins and when modifying an existing profile, it will
update the existing file and preserve the settings plugin.
This Change is about to change the default for `"main.plugins"` from
`"ifcfg-rh,keyfile"` to `"keyfile,ifcfg-rh"`.
== Feedback ==
This was brought up on the NetworkManager mailing list
([https://mail.gnome.org/archives/networkmanager-list/2020-May/msg00002.html
[1]]]).
Fedora CoreOS doesn't use ifcfg-rh files at all, only keyfile. Also,
RHEL CoreOS uses the `"main.plugins=ifcfg-rh,keyfile"` configuration
too. For CoreOS this of course is simpler, because they don't deal
with existing user configurations and tools that would break during
upgrade.
== Benefit to Fedora ==
The long term goal of NetworkManager is to move away from ifcfg-rh
files. That will be difficult as it affects existing installations and
will require migration of existing configurations. This change is only
a first step and affects how NetworkManager by default persists new
profiles to disk.
The ifcfg-rh format arguably has an uglier syntax and, contrary to
keyfile, does not support all profile types. Also, keyfile plugin is
available on every NetworkManager installation because that is the
only plugin that supports all profiles. Having multiple plugins and
file formats is confusing. By now, initscripts' `network-script`
package is deprecated in Fedora and upstream wants to move away from
that format in the long term. Also maintaining multiple settings
plugins is a maintainance burden, and in the past there were subtle
bugs where ifcfg-rh did not implement all settings (e.g.
[https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2020-10754
CVE-2020-10754]). On other Linux distributions NetworkManager uses the
keyfile format by default. It is a general goal that NetworkManager
works similar on all distributions.
== Scope ==
* Proposal owners: The default settings for `"main.plugins"` can
already be selected at compile time. This only requires building the
package with a different default
([https://src.fedoraproject.org/rpms/NetworkManager/blob/a06b38bcbe8f9a38ba...
[3]]).
* Other developers: N/A (not needed for this Change)
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
This affects most users, unless they explicitly set the option in
NetworkManager.conf configuration. The biggest effect of this change
is that new profiles will now preferably be persisted in keyfile
format. This changes behavior for users who expect NetworkManager to
write ifcfg-rh files, or who have scripts or tools that expect that.
What will still work is that existing ifcfg files are loaded after
upgrade. Users who only use the D-Bus API (via one of the client
applications like nmcli or the GUI), shouldn't notice the difference.
As before, users still can explicitly configure the settings plugins
in NetworkManager.conf. This only affects the default, but it affects
existing installations if the user didn't explicitly configure
NetworkManager's `"main.plugins"` option.
The Change will be implemented by changing the compile time default,
instead of dropping a configuration snippet. The reason is that it is
preferably that the installation of NetworkManager avoids extra
configuration. The default behavior should be achived without any
configuration. During package update there would be the possibility to
drop a file `/etc/NetworkManager/02-update-plugins-ifcfg-rh.conf` that
preserves the previous behavior. However, I don't think that is
necessary. After upgrading NetworkManager, it will still read ifcfg-rh
file so for the user it is less necessary to preserve the previous
behavior. Also, dropping configuration snippets during package upgrade
has its own downsides because new installations behave different than
upgraded systems.
== How To Test ==
You can already test the effect by explicitly configuring the setting
which will become the default. For example, add a file
`/etc/NetworkManager/conf.d/99-main-plugins.conf` with content
[main]
plugins=keyfile,ifcfg-rh
== User Experience ==
NetworkManager now preferably uses the keyfile format (INI files).
This format is probably easier to understand to users and also has a
closer resemblance to how the profile is presented in nmcli.
If the user is using NetworkManager tools that use the D-Bus API (like
nmcli or the GUI), then the used storage plugin and format is usually
of no concern for the user.
== Dependencies ==
None
== Contingency Plan ==
The `"main.plugins"` option exists for a long time in NetworkManager.
All that changes here is the default of this option.
* Contingency mechanism: revert the change
* Contingency deadline: beta freeze
* Blocks release? No
== Documentation ==
I am not aware of documentation that gets affected by this.
== Release Notes ==
NetworkManager now prefers the keyfile settings plugin over ifcfg-rh
plugin when writing new connection profiles to disk. Existing ifcfg-rh
files are still handled as before.
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
3 years, 6 months
Fedora Packager Dashboard available for testing
by Josef Skladanka
Hi,
We'd like to announce public testing of the Packager Dashboard - a new
service for Fedora package maintainers aiming to provide all relevant
data: FTBFS/FTI status (from both Bugzilla, Koschei and health check),
orphan warnings, bugzillas, pull requests, active overrides and
updates - at a single place in an easy to read and filter way.
The Dashboard is now available: https://packager.fedorainfracloud.org/
Packager Dashboard leverages caching in the Oraculum backend to
significantly speed-up loading times with comparison to querying all
the relevant resources separately. We, of course, can't cache the
entire Bugzilla, Pagure, Bodhi... so we only cache data for users who
visit Packager Dashboard at least once per 14 days. Please keep in
mind that the first load for a “new” user might take a while. Most of
the data sources are refreshed every hour.
You can use the Dashboard for individual accounts as well as for FAS groups.
We'd love to hear your feedback. Please keep in mind that this is
testing deployment - it's currently running on a server with very
limited resources and we're aiming for production deployment on
CommuniShift during this summer.
Feel free to provide ideas or bug reports at
https://pagure.io/fedora-qa/packager_dashboard or simply send an email
reply to this thread with all kinds of feedback.
I'd like to mention the other people who made this possible:
- Miro Hrončok (churchyard) - Original idea
<https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...>
and ideas for data to display
- František Zatloukal - Backend <https://pagure.io/fedora-qa/oraculum>
- Lukáš Brabec - Frontend <https://pagure.io/fedora-qa/packager_dashboard>
Josef
3 years, 7 months
Fedora 32 system-wide change proposal: reduce installation media size
by improving the compression ratio of SquashFS filesystem
by Bohdan Khomutskyi
Summary
Improve compression ratio of SquashFS filesystem on the installation media.
Owner
Name: Bohdan Khomutskyi
Email: bkhomuts(a)redhat.com
Current status
Targeted release: I propose this change for Fedora 32
Last updated: Jan 5 2020
Pagure.io issue: https://pagure.io/releng/issue/9127
I was unable to create an article in Fedora wiki system.
Detailed Description
As of Fedora 31, the LiveOS/squashfs.img file on the installation image, is
compressed with default settings of mksquashfs. The standard configuration
is set to XZ algorithm with block size of 128k and BCJ filter enabled.
Those parameters can be adjusted which will lead to a better compression
ratio and/or reduction of the CPU usage at build time.
This is simple to achieve. Recently, Lorax has gotten support[1] for
adjusting the compression options for mksquashfs via the configuration
file. The file should be altered as following:
[compression]
bcj = yes
args = -b 1M -Xdict-size 1M -no-recovery
Where -b 1M and -Xdict-size 1M are block and dictionary sizes respectively.
Could be adjusted.
Benefit to Fedora
-
Reduction of the installation media size and the cost of storing and
distributing Fedora.
-
Reduction of the CPU usage at build time. Depending on which compression
parameters chosen.
-
See a graphical detail at https://pagure.io/releng/issue/9127.
Scope
-
Proposal owners:
The build environment should have support for adjusting the Lorax
configuration file.. Lorax is a program that produces the
LiveOS/squashfs.img file on the installation media.
One of the way to allow for such customization, is to add a feature in
Pungi, to allow for passing -c option to Lorax.
-
Release engineering: #9127 <https://pagure.io/releng/issue/9127>
-
Policies and guidelines: N/A
-
Trademark approval: N/A
Upgrade/compatibility impact
-
This change comes at a cost of higher memory usage during the
installation. Based on my personal estimations, this should not be the
issue. Since the decompression should require up to 1MiB per thread.
User Experience
-
Increasing the block size on the current configuration with EXT4 file
system, should increase latency while accessing the EXT4 filesystem. The
exact impact is to be evaluated.
-
The impact of latency will be reduced, if the plain SquashFS option is
be choosen.
Dependencies
-
N/A
Contingency Plan
-
N/A
Documentation
https://pagure.io/releng/issue/9127.
mksquashfs(1)
Release notes See also
https://pagure.io/releng/issue/8646
--
Bohdan Khomutskyi
Release Configuration Management engineer
Red Hat
3 years, 7 months
Fedora 33 System-Wide Change proposal: Fedora-Retired-Packages
by Ben Cotton
https://fedoraproject.org/wiki/Changes/Fedora-Retired-Packages
== Summary ==
All retired packages are obsoleted by `fedora-retired-packages`.
== Owner ==
* Name: [[User:msuchy| Miroslav Suchý]]
* Email: msuchy(a)redhat.com
== Detailed Description ==
Right now `fedora-obsoletes-package` retires packages which cause an
issue during an upgrade. We do nothing about all other retired
packages. Now imagine the following story (it already happened many
times):
We have package "foo". It is a leaf package. No one requires it. It
uses just basic libraries.
A user installs it during F32 lifetime.
Around F35 the upstream dies. Around F37 Fedora maintainer retires the
package (or orphan and it later become retired).
Because the package is a leaf package, it causes no pain during
upgrade F37->F38. Not even during upgrade to F39, F40, F41, F42. And
then during upgrade to F43 it suddenly causes a problem. But because
it is .fc37 everyone will hesitate to add it
fedora-obsolete-packages.fc43.
Additionally, during F38-F43, users may expect that their system is
fully updated and they have no security issues. But it is not true
about package "foo", which no one maintains. And users are not aware
of that because he does not follow fedora-devel mailing list.
Obviously.
What I propose is: As part of the retirement process we add the to
fedora-retired-packages:
Obsoletes: foo < %{latestversion+1}
And during upgrade from F37->F38 the package will be removed.
If the user wants to preserve the package (e.g., because it moved to
Copr), he simply uninstalls and protects the installation of
fedora-retired-packages. But that will be an informed decision.
The benefits are:
* we do not leave unmaintained packages on a user's machine.
* We make sure that archaic packages do not break upgrade between two
versions of Fedora.
== Feedback ==
After [https://bugzilla.redhat.com/show_bug.cgi?id=1816532#c5
discussion with fedora-obsolete-package maintainer] I filed this
Change proposal to include a wider audience.
See relevant [https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
thread on devel mailing list].
== Benefit to Fedora ==
* We do not leave unmaintained packages on a user's machine.
* We make sure that archaic packages do not break upgrade between two
versions of Fedora.
== Scope ==
* Proposal owners:
Create package `fedora-retired-packages` as sub-package of
`fedora-obsolete-packages`
[https://bugzilla.redhat.com/show_bug.cgi?id=1816532 BZ#1816532]
Edit https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life#Obs...
guidelines with:
The retired package should be obsoleted by one of:
* fedora-obsoleted-packages - if the package can cause problem during
upgrade to next version of Fedora
* fedora-retired-packages - in all other cases
It is enough to open an issue on
https://src.fedoraproject.org/rpms/fedora-obsolete-packages
* Other developers:
No other work should be necessary.
* Release engineering:
This is optional. I may work with rel-eng to change
https://pagure.io/releng/blob/master/f/docs/source/sop_retire_orphaned_pa...
to automatically create PR for `fedora-obsolete-packages`
* Policies and guidelines: As stated above
https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life#Obs...
will need an update.
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
During an upgrade, all retired packages will be automatically removed.
User may opt-out by:
<pre>
$ cat /etc/dnf/dnf.conf
[main]
...
exclude=fedora-retired-packages
</pre>
== How To Test ==
1. Upgrade to next version of Fedora.
2. Check all retired packages are removed.
== User Experience ==
- Packages that are no longer maintained are removed during a
distribution upgrade.
== Dependencies ==
This update has no dependencies on any other package.
== Contingency Plan ==
* Contingency mechanism: Drop `fedora-retired-package`. Or remove
`Obsoletes` from this sub-package.
* Contingency deadline: Beta freeze
* Blocks release? No
== Documentation ==
TBD
== Release Notes ==
TBD
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
3 years, 7 months
[ELN] Opt out python2.7 from ELN
by Miro Hrončok
Hello,
as a maintainer of the python2.7 package I was surprised to see it being built
for ELN and I like to start a discussion on whether and how can I opt out this
deprecated package from ELN.
Since there is no tracker or dedicated mailing list, I am following the advice
given somewhere else on devel, to use this list, possibly with the [ELN] marker
in subject.
Thanks,
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
3 years, 7 months
Lua 5.4.0
by Tom Callaway
I just built lua 5.4.0 in Rawhide. As with previous major updates of lua,
the package also includes a copy of the lua 5.3 libraries so that rawhide
does not just become broken reps. If you depend on lua, please rebuild your
packages in rawhide and let me know if you run into any issues.
Thanks,
Tom
3 years, 7 months
Fedora 32 System-Wide Change proposal (late): Enable EarlyOOM
by Ben Cotton
https://fedoraproject.org/wiki/Changes/EnableEarlyoom
== Summary ==
Install earlyoom package, and enable it by default. This will cause
the kernel oomkiller to trigger sooner, but will not affect which
process it chooses to kill off. The idea is to recover from out of
memory situations sooner, rather than the typical complete system hang
in which the user has no other choice but to force power off.
== Owner ==
* Name: [[User:chrismurphy| Chris Murphy]]
* Email: bugzilla(a)colorremedies.com
== Detailed Description ==
Workstation working group has discussed "better interactivity in
low-memory situations" for some months. In certain use cases,
typically compiling, if all RAM and swap are completely consumed,
system responsiveness becomes so abysmal that a reasonable user can
consider the system "lost", and resorts to forcing a power off. This
is objective a very bad UX. The broad discussion of this problem, and
some ideas for near term and long term solutions, is located here:
Recent long discussions on "Better interactivity in low-memory situations"<br>
https://pagure.io/fedora-workstation/issue/98<br>
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...<br>
Fedora editions and spins, have the in-kernel OOM (out-of-memory)
manager enabled. The manager's concern is keeping the kernel itself
functioning. It has no concern about user space function or
interactivity. This proposed change attempts to improve the user
experience, in the short term, by triggering the in-kernel process
killing mechanism, sooner. Instead of the system becoming completely
unresponsive for tens of minutes, hours or days, the expectation is an
offending process (determined by oom_score, same as now) will be
killed off within seconds or a few minutes. This is an incremental
improvement in user experience, but admittedly still suboptimal. There
is additional work on-going to improve the user experience further.
Workstation working group discussion specific to enabling earlyoom by default
https://pagure.io/fedora-workstation/issue/119
Other in-progress solutions:<br>
https://gitlab.freedesktop.org/hadess/low-memory-monitor<br>
Background information on this complicated problem:<br>
https://www.kernel.org/doc/gorman/html/understand/understand016.html<br>
https://lwn.net/Articles/317814/<br>
== Benefit to Fedora ==
There are two major benefits to Fedora:
* improved user experience by more quickly regaining control over
one's system, rather than having to force power off in low-memory
situations where there's aggressive swapping. Once a system becomes
unresponsive, it's completely reasonable for the user to assume the
system is lost, but that includes high potential for data loss.
* reducing forced poweroff as the main work around will increase data
collection, improving understanding of low memory situations and how
to handle them better
== Scope ==
* Proposal owners:
a. Modify {{code|https://pagure.io/fedora-comps/blob/master/f/comps-f32.xml.in}}
to include earlyoom package for Workstation.<br>
b. Modify {{code|https://src.fedoraproject.org/rpms/fedora-release/blob/master/f/80-workstation.preset}}
to include:
<pre>
# enable earlyoom by default on workstation
enable earlyoom.service
</pre>
* Other developers:
Restricted to Workstation edition, unless other editions/spins want to opt-in.
* Release engineering: [https://pagure.io/releng/issues #9141] (a
check of an impact with Release Engineering is needed) <!-- REQUIRED
FOR SYSTEM WIDE CHANGES -->
* Policies and guidelines: N/A
* Trademark approval: N/A
== Upgrade/compatibility impact ==
earlyoom.service will be enabled on upgrade. An upgraded system should
exhibit the same behaviors as a clean installed system.
== How To Test ==
* Fedora 30/31 users can test today, any edition or spin:<br>
{{code|sudo dnf install earlyoom}}<br>
{{code|sudo systemctl enable --now earlyoom}}
And then attempt to cause an out of memory situation. Examples:<br>
{{code|tail /dev/zero}}<br>
{{code|https://lkml.org/lkml/2019/8/4/15}}
* Fedora Workstation 32 (and Rawhide) users will see this service is
already enabled. It can be toggled with {{code|sudo systemctl
start/stop earlyoom}} where start means earlyoom is running, and stop
means earlyoom is not running.
== User Experience ==
The most egregious instances this change is trying to mitigate:
a. RAM is completely used
b. Swap is completely used
c. System becomes unresponsive to the user as swap thrashing has ensued
--> earlyoom disabled, the user often gives up and forces power off
(in my own testing this condition lasts >30 minutes with no kernel
triggered oom killer and no recovery)
--> earlyoom enabled, the system likely still becomes unresponsive but
oom killer is triggered in much less time (seconds or a few minutes,
in my testing, after less than 10% RAM and 10% swap is remaining)
earlyoom starts sending SIGTERM once both memory and swap are below
their respective PERCENT setting, default 10%. It sends SIGKILL once
both are below their respective KILL_PERCENT setting, default 5%.
The package includes configuration file /etc/default/earlyoom which
sets option {{code|-r 60}} causing a memory report to be entered into
the journal every minute.
== Dependencies ==
earlyoom package has no dependencies
== Contingency Plan ==
* Contingency mechanism: Owner will revert all changes
* Contingency deadline: Final freeze
* Blocks release? No
* Blocks product? No
== Documentation ==
{{code|man earlyoom}}<br><br>
https://www.kernel.org/doc/gorman/html/understand/understand016.html
== Release Notes ==
Earlyoom service is enabled by default, which will cause kernel
oom-killer to trigger sooner. To revert to previous behavior:<br>
{{code|sudo systemctl disable earlyoom.service}}
And to customize see {{code|man earlyoom}}.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
3 years, 7 months
Headsup: dbus 1.12.10-1.fc29 is missing systemd dbus.service file,
breaking almost everything
by Hans de Goede
Hi All,
Just a quick headsup for users following Fedora 29, the
dbus 1.12.10-1.fc29 build is missing the systemd dbus.service
file, breaking almost everything.
Instead it contains a dbus-daemon.service file, but the
dbus.socket file expects a matching dbus.service, not
dbus-daemon.service.
So either hold of on applying updates until this is fixed
or exclude dbus.
Regards,
Hans
3 years, 7 months