As of GLib 2.90.0 (not yet released), GLib will fully support the spec,
including the `MEMORY_PRESSURE_WATCH` and `MEMORY_PRESSURE_WRITE`
environment variables, which it did not support previously.
See https://gitlab.gnome.org/GNOME/glib/-/merge_requests/5046
(cherry picked from commit 075f74a19c)
(cherry picked from commit 97369d584a)
(cherry picked from commit 64d15be6f0)
(cherry picked from commit ce35320b5c)
804874d26a added a new mode but the
sentence wasn't updated and it was still stating that there are Two modes
instead.
(cherry picked from commit 84d10a9004)
(cherry picked from commit 3ff640df40)
(cherry picked from commit c2038aaa6a)
The claude bot keeps getting this wrong again and again:
Claude: nit: systemd coding style requires braces on both branches of
an if/else when one branch uses them. Here the if branch
is a single statement without braces but the else branch
uses braces
Specifically mention this is not the case in the coding style doc
to hopefully make it stop hallucinating this rule
(cherry picked from commit 36896a27b1)
(cherry picked from commit e0e731c653)
(cherry picked from commit ce4ffe001f)
Fix two issues in WRITING_VM_AND_CONTAINER_MANAGERS.md:
1. The Host OS Integration section implied that -M switch and
machinectl shell/login work for VMs, but they currently only
work for containers. Add a note clarifying this limitation.
2. The Guest OS Integration section said "there's only one" VM
integration API (SMBIOS Product UUID), but VM_INTERFACE.md
documents five. Replace the outdated single-API description
with a reference to VM_INTERFACE.md listing all five.
Fixes#40935
Co-developed-by: Claude Opus 4.6 <noreply@anthropic.com>
(cherry picked from commit adc4757b9e)
(cherry picked from commit 385dc8fb38)
(cherry picked from commit a256323c8e)
Markdown and HTML don't support mixing ordered and unordered items
within a single list. This means the previous syntax actually produced
three separate lists.
Also, markdown converters don't necesarrily respect the first number in
an ordered list, and may just overwrite it to one. This is the case for
the one that generates the systemd.io page. And even if that wasn't the
case, the numbering of the second ordered list would be off by one.
(cherry picked from commit f377be7081)
(cherry picked from commit 5665b14945)
(cherry picked from commit 656670df9d)
`max-width: 100%` keeps images from expanding beyond
their container and creating horizontal overflow scroll
on small screens.
`height: auto` ensures the image scales proportionally
when width is adjusted.
(cherry picked from commit e5a6cc3a6f)
(cherry picked from commit 6c6b635b8a)
Unprivileged processes can send 768M in a FD-based message to journald,
which will be malloc'ed in one go, likely causing memory issues.
Set the limit for unprivileged users to 24M.
Allow coredumps as an exception, since we always allowed storing
up to the 768M max core files in the journal.
Reported on yeswehack.com as #YWH-PGM9780-48
(cherry picked from commit e67b008fa3)
(cherry picked from commit d33dbbc613)
I had to sketch this out before I could get the internals of
systemd-sysupdate straight in my head, particularly around how an
`UpdateSet` points to one `Instance` from each of a set of `Resource`s,
and those `Instance`s are either all sources or all targets.
Hopefully this is useful to the next person to look at the code.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
(cherry picked from commit a05439097f)
(cherry picked from commit 877b9f9a0d)
I was looking into a question posed in one of the Fedora discussion threads:
is it OK for a package to assume that files in different directories under /usr
are always on the same mount point? rpmlint emits a warning if a package has
files that are hardlinked between directories, i.e. rpmlint thinks that this
is not the case. But in practice, our systems are like this and our tooling
generally doesn't expect a part of /usr to be separated out. I looked at the
MOUNT_REQUIREMENTS document, but it doesn't answer this question clearly.
It was clearly written with the assumption that e.g. "/usr/" or "/var/" are one
mount point, so when it is "mounted", all of it is available. But the document
also talks about submounts being pulled in through requirements on specific
units, which requires some mounts not to be mounted all at once, so the reader
is left without any direct answer to this question.
This rewrite makes the following changes:
- rename "generally three categories of requirements" to
"three general categories of mount points" because we're categorizing
mount points, not requirements.
- always repeat the category name in further mentions,
e.g. "2/early" instead of just "2" so the reader doesn't have to jump
back to the table when reading.
- mention that it is OK for a mount point to be not split out
- say that submount which is "conceptually separate" may be mounted
later.
- say "ephemeral system" instead of "stateless system" and split out
the description of those systems into a separate paragraph and clearly
state that they are an exception that skips the requirements listed in
this document.
- be consistent in specifying the boundary before which each category must
have been mounted. Previously, cat. 1 was described as "before transisition"
and cat. 2 was described as "during early boot", which created the additional
problem that later we needed to contradict this saying that "must be mounted
during early boot" doesn't actually mean that and this can be done ealier.
If we say "before end of early boot", we avoid this awkwardness.
(cherry picked from commit 3e94ae6f1e)
See https://gitlab.gnome.org/GNOME/glib/-/issues/2931 for the changes in
GLib upstream. Using `GMemoryMonitor` is now more compliant with the
systemd recommended approach, but it needs further work to read the
recommended environment variables rather than unconditionally accessing
the per-cgroup PSI kernel file directly.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
(cherry picked from commit 69f1a1d5ed)
This has been tripping up container manager people. let's document this
explicitly.
(Note that the container interface could really use some updates, i.e.
it was written before a time where cgroup namespacing was a thing. But I
am too lazy to fix that now, so let's just add this once facet.)
(cherry picked from commit 32f4e30be5)
0x1770 is 6000, not 60000. It looks like 60000 is intended (the next
range starts at 60000 in both decimal and hex), so use that.
1000 to 60000 is 59001 users, as the range is inclusive on both sides.
Similar off-by-one for one of the "unused" ranges. After these changes,
the sizes of the ranges up to and including the "-1" ID sum up to 65536,
as expected.
I'm not sure where the size of the unused range after the container UID
range came from, but it is not correct (the "Container UID" and this
reserved range combined would be larger than the "HIC SVNT LEONES" 2^31
to 2^32-2 range...). Fix it.
It is unfortunate that the first half of this table makes more sense in
decimal while the second half makes more sense in hex (which would also
make the size in 65536 chunks easy to obtain): I'm tempted to add a
"sizes in hex" column...
(cherry picked from commit 1599b6fbe2)
