Let's make sure we clean up after ourselves. We have to remove
the generated timeout user config file, the file list files and the
generated .lang file.
... (rhbz#2217997)
systemd-homed.service and systemd-portabled.service are in
systemd-udev but the scriptlet was attached to main subpackage, so it
wouldn't work because the unit file wasn't installed yet when it was
invoked. systemd-pstore.service and remote-cryptsetup.target were
forgotten, so they wouldn't get enabled on installation.
Rpm >= 4.19 has native sysusers integration and generates similar
user() and group() provides but encodes additional information into
them, information that is required for the rpm integration to work.
Besides additional data, one noteworthy difference in the rpm generated
provides is there are no provides generated for m(ember) directives.
This is because users and groups possibly created by that directive are
a too implicit for dependency resolution and install ordering purposes
in the case where the user/group is actually owned by some other package.
... (rhbz#2177722)
Oomd was killing a login session (user-*.slice/session-*.scope).
Quoting https://bugzilla.redhat.com/show_bug.cgi?id=2177722#c21:
> In F37 and prior the config was killing based on swap and pressure
> on user-*.slice/user@.service. In 7665e1796f
> it was changed to pressure only on system.slice and all slices under
> user.slice. The relevant point here is that this change now includes
> user-*.slice/session-*.scope which is the critical session bits
> you're seeing killed here.
>
> That session scope should be omitted. The config that I intended
> with the initial PR was for all slices under
> user.slice/user-*.slice/user@.service to be monitored, not for all
> slices under user.slice.
With the file removed:
$ oomctl | rg Path | sort
Path: /system.slice
Path: /user.slice/user-1000.slice/user@1000.service/app.slice
Path: /user.slice/user-1000.slice/user@1000.service/session.slice
See https://github.com/systemd/systemd/pull/26641.
This will allow upstream pull request (and the main branch after the pull
request has been merged) to be built with the new code. This doesn't do
anything for official rpm builds until the new code is part of the sources.
[skip changelog]
... (rhbz#2164594)
The socket exists and is enabled in the initrd. After switch-root, the system
goes into an infinite loop trying to stop the socket while incoming audit
messages trigger start jobs for the socket. This is a bug in the transaction
logic, that'll need to be fixed separately.
We need to preset the socket after the upgrade so that it remains enabled
by default. This should fix the boot issue, though it's not a complete fix,
because we actually want to allow people to disable the socket.
On initial install, the socket is covered by preset-all and gets enabled.
gcc has a new warning which caught a bug of int/enum mismatches.
And we would crash on some architectures when built with -D_FORTIFY_SOURCE=3
because of our malloc_usable_size() use.
This should resolve the build failure in F38 mass build.
- Fixes a few different issues (systemd-timesyncd connectivity problems, broken
emoji output on the console, crashes in pid1 unit dependency logic)
- CVE-2022-4415: systemd: coredump not respecting fs.suid_dumpable kernel
setting
As requested in https://github.com/rhinstaller/anaconda/pull/4368#discussion_r1043839809,
so that it's easier to depend on the appropriate package. Once we have the
signed version built, this provides might be dropped. But let's add it at least
for now so that there's a stable name to depend on.
While at it, let's drop ? from %{_isa}. Systemd is always archful.
This file changes rarely, but it does every one in a while. And since we have an
independent copy, we forget to adjust it. We have had already two bugs because
of this. I submitted a PR upstream to include pam_namespace (because that makes
sense for all distros), so the diff between upstream and us now is just the
inclusion of system-auth (which is not upstreamable).
Effectively, the only difference right now is that 'pam_keyinit force revoke'
is included. It was added upstream with the comment:
We want that systemd --user gets its own keyring as usual, even if the
barebones PAM snippet we ship upstream is used. If we don't do this we get
the basic keyring systemd --system sets up for us.
Daan De Meyer
Zbigniew Jędrzejewski-Szmek
Stewart Smith
Stewart Smith
Yaakov Selkowitz
Panu Matilainen
Anita Zhang
Alessandro Astone
Dusty Mabe
Thomas Haller
Michael Catanzaro