Do not make up our own type for ExitStatus, but use the type used by POSIX for
this, which is "int". In particular as we never used that type outside of the
definition of exit_status_to_string() where we internally cast the paramter to
(int) every single time we used it.
Hence, let's simplify things, drop the type and use the kernel type directly.
It is impossible to ship a fully generic PAM configuration upstream.
Therefore, ship a minimal configuration with the systemd --user requirements,
and add a note to DISTRO_PORTING documenting this.
Fixes#4284
console-shell.service was supposed to be useful for normal clean boots
(i.e. multi-user.target or so), as a replacement for logind/getty@.service for
simpler use cases.
But due to the lack of documentation and sanity check one can easily be
confused and enable this service in // with getty@.service.
In this case we end up with both services sharing the same tty which ends up in
strange results.
Even worse, console-shell.service might be failing while getty@.service tries
to acquire the terminal which ends up in the system to poweroff since
console-shell.service uses:
"ExecStopPost=-/usr/bin/systemctl poweroff".
Another issue: this service doesn't work well if plymouth is also used since it
lets the splash screen program run and mess the tty (at least a "plymouth quit"
is missing).
So let's kill it for now.
systemd fills arg_default_unit during startup with default.target
value. But arg_default_unit may be overwritten in parse_argv() or
parse_proc_cmdline_item().
Let's check value of arg_default_unit after calls of parse_argv()
and parse_proc_cmdline_item() and fill it with default.target if
it wasn't filled before. In this way we will not spend unnecessary
time to for filling arg_default_unit with default.target.
When running in a user namespace without private networking, resolved would
fail to start. There isn't much difference between EADDRINUSE and EPERM,
so treat them the same, except for the warning message text.
Make sure an error is always printed… When systemd-resolved is started in a
user namespace without private network, it would fail on setsockopt, but the
error wouldn't be particularly informative:
"Failed to start manager: permission denied."
According to TCG EFI Protocol Specification for TPM 2.0 family,
all events generated after the invocation of EFI_TCG2_GET_EVENT_LOG
shall be stored in an instance of an EFI_CONFIGURATION_TABLE aka
EFI TCG 2.0 final events table. Hence, it is necessary to trigger the
internal switch through calling get_event_log() in order to allow
to retrieve the logs from OS runtime.
msekletar:
> I've looked at EDK2 and indeed log entry is added to FinalEventsTable only after
> EFI_TCG2_PROTOCOL.GetEventLog was called[1][2]. Also, same patch was currently
> merged to shim by Peter Jones [3].
[1] https://github.com/tianocore/edk2/blob/master/SecurityPkg/Tcg/Tcg2Dxe/Tcg2Dxe.c#L698
[2] https://github.com/tianocore/edk2/blob/master/SecurityPkg/Tcg/Tcg2Dxe/Tcg2Dxe.c#L824
[3] rhinstaller/shim#64
The documentation says lists "yes", "no", "pick", and numeric arguments.
But parse_boolean was attempted first, so various numeric arguments were
misinterpreted.
In particular, this fixes --private-users=0 to mean the same thing as
--private-users=0:65536.
While at it, use strndupa to avoid some error handling.
Also give a better error for an empty UID range. I think it's likely that
people will use --private-users=0:0 thinking that the argument means UID:GID.
Current systemd version detection routine cannot detect systemd 230,
only systmed >= 231. This means that we'll still use the legacy hierarchy
in some cases where we wouldn't have too. If somebody figures out a nice
way to detect systemd 230 this can be later improved.
systemd-soon-to-be-released-232 is able to deal with the mixed hierarchy.
So make an educated guess, and use the mixed hierarchy in that case.
Tested by running the host with mixed hierarchy (i.e. simply using a recent
kernel with systemd from git), and booting first a container with older systemd,
and then one with a newer systemd.
Fixes#4008.
The new function has 416 lines by itself!
"return log_error_errno" is used to nicely reduce the volume of error
handling code.
A few minor issues are fixed on the way:
- positive value was used as error value (EIO), causing systemd-nspawn
to return success, even though it shouldn't.
- In two places random values were used as error status, when the
actual value was in an unusual place (etc_password_lock, notify_socket).
Those are the only functional changes.
There is another potential issue, which is marked with a comment, and left
unresolved: the container can also return 133 by itself, causing a spurious
reboot.
This adds a new invocation ID concept to the service manager. The invocation ID
identifies each runtime cycle of a unit uniquely. A new randomized 128bit ID is
generated each time a unit moves from and inactive to an activating or active
state.
The primary usecase for this concept is to connect the runtime data PID 1
maintains about a service with the offline data the journal stores about it.
Previously we'd use the unit name plus start/stop times, which however is
highly racy since the journal will generally process log data after the service
already ended.
The "invocation ID" kinda matches the "boot ID" concept of the Linux kernel,
except that it applies to an individual unit instead of the whole system.
The invocation ID is passed to the activated processes as environment variable.
It is additionally stored as extended attribute on the cgroup of the unit. The
latter is used by journald to automatically retrieve it for each log logged
message and attach it to the log entry. The environment variable is very easily
accessible, even for unprivileged services. OTOH the extended attribute is only
accessible to privileged processes (this is because cgroupfs only supports the
"trusted." xattr namespace, not "user."). The environment variable may be
altered by services, the extended attribute may not be, hence is the better
choice for the journal.
Note that reading the invocation ID off the extended attribute from journald is
racy, similar to the way reading the unit name for a logging process is.
This patch adds APIs to read the invocation ID to sd-id128:
sd_id128_get_invocation() may be used in a similar fashion to
sd_id128_get_boot().
PID1's own logging is updated to always include the invocation ID when it logs
information about a unit.
A new bus call GetUnitByInvocationID() is added that allows retrieving a bus
path to a unit by its invocation ID. The bus path is built using the invocation
ID, thus providing a path for referring to a unit that is valid only for the
current runtime cycleof it.
Outlook for the future: should the kernel eventually allow passing of cgroup
information along AF_UNIX/SOCK_DGRAM messages via a unique cgroup id, then we
can alter the invocation ID to be generated as hash from that rather than
entirely randomly. This way we can derive the invocation race-freely from the
messages.
Let's make sure people invoking STRV_FOREACH_BACKWARDS() as a single statement
of an if statement don't fall into a trap, and find the tail for the list via
strv_length().
This patch adds support to remote checksum checksum offload to VXLAN.
This patch adds RemoteCheckSumTx and RemoteCheckSumRx vxlan configuration
to enable remote checksum offload for transmit and receive on the VXLAN tunnel.
RISC-V is an open source ISA in development since 2010 at UCB.
For more information, see https://riscv.org/
I am adding RISC-V support to Fedora:
https://fedoraproject.org/wiki/Architectures/RISC-V
There are three major variants of the architecture (32-, 64- and
128-bit). The 128-bit variant is a paper exercise, but the other
two really exist in silicon. RISC-V is always little endian.
On Linux, the default kernel uname(2) can return "riscv" for all
variants. However a patch was added recently which makes the kernel
return one of "riscv32" or "riscv64" (or in future "riscv128"). So
systemd should be prepared to handle any of "riscv", "riscv32" or
"riscv64" (in future, "riscv128" but that is not included in the
current patch). If the kernel returns "riscv" then you need to use
the pointer size in order to know the real variant.
The Fedora/RISC-V kernel only ever returns "riscv64" since we're
only doing Fedora for 64 bit at the moment, and we've patched the
kernel so it doesn't return "riscv".
As well as the major bitsize variants, there are also architecture
extensions. However I'm trying to ensure that uname(2) does *not*
return any other information about those in utsname.machine, so that
we don't end up with "riscv64abcde" nonsense. Instead those
extensions will be exposed in /proc/cpuinfo similar to how flags
work in x86.
Let's not accept datagrams with embedded NUL bytes. Previously we'd simply
ignore everything after the first NUL byte. But given that sending us that is
pretty ugly let's instead complain and refuse.
With this change we'll only accept messages that have exactly zero or one NUL
bytes at the very end of the datagram.
Let's make the kernel let us know the full, original datagram size of the
incoming message. If it's larger than the buffer space provided by us, drop the
whole message with a warning.
Before this change the kernel would truncate the message for us to the buffer
space provided, and we'd not complain about this, and simply process the
incomplete message as far as it made sense.
If the kernel doesn't permit us to dequeue/process an incoming notification
datagram message it's still better to stop processing the notification messages
altogether than to enter a busy loop where we keep getting notified but can't
do a thing about it.
With this change, manager_dispatch_notify_fd() behaviour is changed like this:
- if an error indicating a spurious wake-up is seen on recvmsg(), ignore it
(EAGAIN/EINTR)
- if any other error is seen on recvmsg() propagate it, thus disabling
processing of further wakeups
- if any error is seen on later code in the function, warn about it but do not
propagate it, as in this cas we're not going to busy loop as the offending
message is already dequeued.
For some certification, it should not be possible to reboot the machine through ctrl-alt-delete. Currently we suggest our customers to mask the ctrl-alt-delete target, but that is obviously not enough.
Patching the keymaps to disable that is really not a way to go for them, because the settings need to be easily checked by some SCAP tools.
