IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Let's make sure logind is accessible by the time user@.service runs, and
that logind stays around as long as it does so.
Addresses an issue reported here:
https://lists.freedesktop.org/archives/systemd-devel/2024-June/050468.html
This addresses an issued introduced by
278e815bfa, which dropped the a dependency
from user@.service systemd-user-sessions.service without replacement.
While dropping that dependency does make sense, it should have been
replaced with the weaker dependency on systemd-logind.service, hence fix
that now.
user@.service is after all a logind concept, hence logind really should
be around for its lifetime.
systemd-user-sessions.service is a later milestone that only really
should apply to regular users (not root), hence it's too strong a
requirement.
(cherry picked from commit 29294d21cf)
Historically, systemd-tmpfiles was designed to manager temporary
files, but nowadays it has become a generic tool for managing
all kinds of files. To avoid user confusion, let's remove "temporary"
from the tool's description.
As discussed in #33349
(cherry picked from commit b5c8cc0a3b)
The TPM might be password/pin protected for various reasons even if
there is no SRK yet. Let's handle those cases gracefully instead of
failing the unit as it is enabled by default.
(cherry picked from commit d6518003f8)
Enabling this service by default means every CI image without a
regular user now gets stuck on first boot due to the password prompt
from systemd-homed-firstboot.service. Let's not enable the service
by default but instead require users to enable it explicitly if they
want its behavior.
Fixes#33249
A unit with StandardOutput=journal (the default) will get its stdout/stderr sockets
disconnected when journald stops, as the file descriptors on journald's side are
not preserved (it works on restart, as the FD Store keeps them open during restarts).
Set FileDescriptorStorePreserve=yes so that the journal FD's stay open during a soft
reboot, and applications don't get broken stdout/stderr.
After soft-reboot, /var/log/journal may be initially read-only,
and becomes writable a bit later. In such case, runtime journal is
initially opened by journald. Hence, we need to flush to /var when it is
ready.
Typically, soft-reboot.target is never reached. So, without this change,
systemd-journald may be killed by PID1 on soft-reboot, and may cause
journal corruption.
This reverts commit 4263d7617f.
Still I think this is the way to go. But the change was merged after -rc2,
and still discussion is continued. So, at least now let's revert it,
and do that after v256-final is released if approved.
Otherwise, at the time systemd-soft-reboot.service succeeds,
services which has Conflicts= and Before=soft-reboot.target may
not be stopped yet, and may be SIGKILLed.
Especially, systemd-journald.service has the dependencies, thus
journal may be corrupted. See #32223.
Follow-up for 13ffc60749.
Fixes#32834.
The service deos not have DefaultDependencies=no. Hence it has dependencies
of shutdown.target, and dependencies of soft-reboot.target are not
necessary.
Follow-up for f89985ca49.
Otherwise, if a service unit that requests LogNamespace= stopped before
systemd-journald@.service is started, logs generated by the service will be
lost, as systemd-journald@.socket is stopped and
systemd-journald@.service will never started.
To prevent the issue, let's introduce another implicit dependency to
a oneshot service that explicitly synchronizes a namespaced journal file
when the log namespace is not needed anymore.
Fixes#32604.
It's ordered with networkd, but just in case. Lintian complains:
W: systemd: systemd-service-file-shutdown-problems [usr/lib/systemd/system/systemd-networkd-persistent-storage.service]
Follow-up for 91676b6458
Right now systemd-tpm2-setup-early and systemd-pcrphase-initrd.service
are not ordered against each other. However, they require the same slow
resource to operate: the TPM2. If we allow them to access the device
simultaneously, the kernel resource manager like has to save/restore TPM
state while they operate, slowing things down further.
hence, let's avoid all this mess, and just order them against each other
so that the shared resource is first used in full by one and then by the
other.
I opted to order systemd-pcrphase-initrd before
systemd-tpm2-setup-early, since there's value in having the former as
early as possible in userspace, to be a good marker for the transition
from kernel to first userspace. I can see no benefit in the opposite
order however.
This mimics what we do for systemd-cryptsetup@.service (see
src/shared/generator.c), and makes sense since repart might lock up the
root volume against a TPM, which ideally has its SRK already set up by
then.
More importantly though, this ensures that we ordered correctly after
tpm2.target (which systemd-tpm2-setup-early.service has a dependency
on), for systems where the TPM drivers are not compiled into the kernel.
See: https://lists.freedesktop.org/archives/systemd-devel/2024-April/050201.html
This adds a small, socket-activated Varlink daemon that can delegate UID
ranges for user namespaces to clients asking for it.
The primary call is AllocateUserRange() where the user passes in an
uninitialized userns fd, which is then set up.
There are other calls that allow assigning a mount fd to a userns
allocated that way, to set up permissions for a cgroup subtree, and to
allocate a veth for such a user namespace.
Since the UID assignments are supposed to be transitive, i.e. not
permanent, care is taken to ensure that users cannot create inodes owned
by these UIDs, so that persistancy cannot be acquired. This is
implemented via a BPF-LSM module that ensures that any member of a
userns allocated that way cannot create files unless the mount it
operates on is owned by the userns itself, or is explicitly
allowelisted.
BPF LSM program with contributions from Alexei Starovoitov.
stale HibernateLocation EFI variable
Currently, if the HibernateLocation EFI variable exists,
but we failed to resume from it, the boot carries on
without clearing the stale variable. Therefore, the subsequent
boots would still be waiting for the device timeout,
unless the variable is purged manually.
There's no point to keep trying to resume after a successful
switch-root, because the hibernation image state
would have been invalidated by then. OTOH, we don't
want to clear the variable prematurely either,
i.e. in initrd, since if the resume device is the same
as root one, the boot won't succeed and the user might
be able to try resuming again. So, let's introduce a
unit that only runs after switch-root and clears the var.
Fixes#32021
Drop connections and caches and reload config from files, to allow
for low-interruptions updates, and hook up to the usual SIGHUP and
ExecReload=. Mark servers and services configured directly via D-Bus
so that they can be kept around, and only the configuration file
settings are dropped and reloaded.
Fixes https://github.com/systemd/systemd/issues/17503
Fixes https://github.com/systemd/systemd/issues/20604
c0aeff4b99 added this in one unit file, but the
same problem occurs here. (There are no other files where this would apply.)
I think we should solve this systematically somehow, but it's not clear how to
do that, so until we have that better solution, let's apply the manual solution
so that our units work as expected.
Now, networkd accesses the state directory through the file descriptor
passed from systemd-networkd-persistent-storage.service.
Hence, the networkd itself does not need to access the state directory
through its path, and we can use more stronger mode for ProtectSystem=.
Currently the associated units fail if full tpm support is not available
on the system. Similar to systemd-pcrextend, let's add a --graceful option
that exits gracefully if no full TPM support is detected and use it in both
units.
This new passive target is supposed to be pulled in by SSH
implementations and should be reached when remote SSH access is
possible. The idea is that this target can be used as indicator for
other components to determine if and when SSH access is possible.
One specific usecase for this is the new sd_notify() logic in PID 1 that
sends its own supervisor notifications whenever target units are
reached. This can be used to precisely schedule SSH connections from
host to VM/container, or just to identify systems where SSH is even
available.
"Starting Boot Control…" would be a fairly confusing message in the boot logs.
Use "… Service" to mirror what we have in other services like
systemd-{hostnamed,timedated,portabled,machined,…}.service.
We generally don't specify the protocol implementation in unit descriptions.
For journald, we have:
$ git grep Description 'units/*journald*'
units/systemd-journald-audit.socket:Description=Journal Audit Socket
units/systemd-journald-dev-log.socket:Description=Journal Socket (/dev/log)
units/systemd-journald-varlink@.socket:Description=Journal Varlink Socket for Namespace %i
units/systemd-journald.service.in:Description=Journal Service
units/systemd-journald.socket:Description=Journal Sockets
units/systemd-journald@.service.in:Description=Journal Service for Namespace %i
units/systemd-journald@.socket:Description=Journal Sockets for Namespace %i
so we need to keep "Varlink" in the name. But also use "Sockets" (plural)
for the "main" socket unit, since it opens multiple sockets.
I was looking at the logs in some bug and saw this:
Mar 13 15:55:12 fedora systemd[1]: systemd-pcrmachine.service - TPM2 PCR Machine ID Measurement was skipped because of an unmet condition check (ConditionSecurity=measured-uki).
Mar 13 15:55:12 fedora systemd[1]: Starting systemd-remount-fs.service - Remount Root and Kernel File Systems...
Mar 13 15:55:12 fedora systemd[1]: systemd-tpm2-setup-early.service - TPM2 SRK Setup (Early) was skipped because of an unmet condition check (ConditionSecurity=measured-uki).
This is overly technical, for most units we don't provide this level of
detail about the implementation. So retitle the units to be more accessible.
Also, the fact that it's a v. 2 of the TPM is not that important. We don't
support TPM 1.2, but computers without TPM v2 are getting rare. For other
units we don't advertise the version of hardware, and let's not do this here,
to reduce some complexity.
In mkosi, we've been having CI failures caused by
systemd-machine-id-commit.service timing out. Let's bump the timeout
for it and systemd-rfkill.service to 90s which we also use for other
oneshot services to avoid transient failures on slower systems.
ProtectSystem=full remounts /boot and/or /efi read-only, but that
may trigger automount for the paths and delay the service being started.
===
systemd[1]: boot.automount: Got automount request for /boot, triggered by 720 ((networkd))
===
The service does not need to access the paths, so let's hide them.
Follow-up for f90eb08627.
Fixes#31742.
Then, this introduces systemd-networkd-persistent-storage.service.
systemd-networkd.service is an early starting service. So, at the time
it is started, the persistent storage for the service may not be ready,
and we cannot use StateDirectory=systemd/network in
systemd-networkd.service.
The newly added systemd-networkd-persistent-storage.service creates the
state directory for networkd, and notify systemd-networkd that the
directory is usable.
Most of our kernel cmdline options use underscores as word separators in
kernel cmdline options, but there were some exceptions. Let's fix those,
and also use underscores.
Since our /proc/cmdline parsers don't distinguish between the two
characters anyway this should not break anything, but makes sure our own
codebase (and in particular docs and log messages) are internally
consistent.
