Drops the global-optind dependency from the test helper. Verb fixtures
stay inline as static const Verb[] — the section-based VERB() macro
would force unique verb names across the three test cases, which they
deliberately share to exercise overlap.
Co-developed-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Place VERB() declarations above each dispatch function and use
verbs_get_help_table() in help(). run() switches to
dispatch_verb_with_args(); the argv_looks_like_help() shortcut is
preserved since this is an internal tool with no proper option parsing.
Co-developed-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
There is no --help implemented, so both verbs don't get help strings.
We should probably add --help + --version, and a proper description
of the program, but I'm leaving that for later.
Co-developed-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Place VERB() declarations above each dispatch function and use
verbs_get_help_table() in help() so the command listing stays in sync.
run() switches to dispatch_verb_with_args(); the argv_looks_like_help()
shortcut is preserved since this is an internal tool with no proper
option parsing.
Co-developed-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Place VERB() declarations directly above each dispatch function and use
verbs_get_help_table() in help() so the command listing stays in sync.
run() switches to dispatch_verb_with_args(); the argv_looks_like_help()
shortcut is preserved since this is an internal tool with no proper
option parsing.
Co-developed-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This is the util-linux mount-helper interface (mount.storage), so all
options stay hidden via help=NULL — they are not user-facing. The
namespace "mount.storage" is distinct from the storagectl namespace
used for the user-facing CLI.
Co-developed-by: Claude Opus 4.7 <noreply@anthropic.com>
This bothered me for a while, but I didn't think too much about it and just
copied the existing usage pattern. But it really doesn't make sense. We expect
the compiler to align the section properly. But if it didn't align it, applying
alignment after the fact would just cause our pointer to point to the middle
of the structure. That'd be even worse than a misaligned pointer.
Similarly, when doing pointer arithmetic, p++ should really result in a value
with the appropriate alignment. This is the basic principle of C pointer
addition. So we really shouldn't try to adjust the pointer ourselves. At most,
we can assert that it is indeed aligned in tests.
For the shell verb we want switches specified after the program name to
be passed to the program to execute, not processed by us. Mirror the
approach in 'userdbctl ssh-authorized-keys': start with
OPTION_PARSER_RETURN_POSITIONAL_ARGS, then lates switch to
STOP_AT_FIRST_NONOPTION for "shell" or NORMAL otherwise.
VERB declarations are placed directly above each function; functions
that dispatch multiple verb names get stacked VERB() declarations.
chainload_importctl() now takes the args strv instead of relying on the
global optind.
--help output is mostly the same.
--no-pager/--no-legend/--no-ask-password/-q/--quiet are now at the end.
bind-volume/unbind-volume are documented.
Fixes c9f461a806.
Co-developed-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The net diff is negative because some spurious whitespace and forward
declarations were dropped. One new forward declaration was added. (For
verb_poweroff_machine. The func could be moved, but I think it's better
to keep it adjacent to verb_reboot_machine which is very similar.)
--help looks pretty much the same. "[list]" is shown in parentheses
because it's the default.
Co-developed-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Rewrite help() with help-util.h primitives + option_parser_get_help_table_group
for each User Record Properties section. The verbs[] table stays
unchanged for now; run() switches from dispatch_verb() (which depended
on the global optind) to _dispatch_verb_with_args() fed by
option_parser_get_args().
Explanations are improved for --birth-date[=DATE] (correct placement of
'['), --skel=, --shell= (short options listed). Some minor rewordings
for other options. The explanation for -E and -EE is split.
(OPTION_HELP_ENTRY_VERBATIM is used for -EE.)
Co-developed-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Display options --no-pager, --no-legend, --no-ask-password are placed at
the end, after --mute-console=yes, rather than near the top.
Co-developed-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Just a hand-crafted moving of blocks of code up and down, no other
changes. The net diff is -2 because add_signing_keys_from_credentials
forward declaration was dropped.
First of all, FD store propagation is enabled between manager instances,
and nspawn instances, via LISTEN_FDS and sd_notify. These can be nested
arbitrarily deeply all the way up to the system manager, and on restart
will be propagated all the way down to the origin. The FDs payload of an
nspawn container running as a user unit will be preserved, all the way
up to the system manager, and then down again.
The kernel Live Update Orchestrator (LUO) exposes /dev/liveupdate, which
lets userspace hand a set of "preservable" kernel objects to the new
kernel across a kexec-based reboot. For now it only supports memfds,
with more object types (virtio devices, etc.) expected to be added
later.
This is a natural fit for systemd's FD Store feature: services hand
memfds (containing serialized state or other service data) to PID 1 via
FDSTORE=1 sd_notify() messages, and get them back on their next start.
Today this works across service restarts, soft reboots and initrd→rootfs
transitions. With LUO, this series extends the same mechanism to work
across kexec too. The nesting preservation of FD stores thus now is
extended across kexec.
All preservable fds are collected into a single LUO session named
"systemd". Each fd is uploaded with an index (token). Token 0 is
reserved for a "mapping" memfd, which carries a JSON object describing
how to dispatch the other tokens back to units on the next boot.
Unit names are used as the unit identifier, as they are stable across
daemon-reexec, switch-root and kexec. token refers to the LUO index
assigned to the object in the session.
On shutdown for MANAGER_KEXEC, just before manager_free(), systemd walks
all services and serializes their persistent fd store contents (fds +
FDNAMEs + cgroup paths) into a JSON memfd. The fds themselves are
gathered into an FDSet. The fdset and the serialization memfd are passed
to systemd-shutdown via the SYSTEMD_LUO_SERIALIZE_FD environment
variable providing the fd number, so the actual LUO session creation and
ioctls happen as the very last step before kexec.
On boot, manager_luo_restore_fd_stores() opens /dev/liveupdate, tries to
retrieve the "systemd" session, reads the mapping memfd, then for each
entry retrieves the fd from the session and attempts to attach it to the
matching unit's fd store.
Because the initrd-stage PID 1 runs before the real rootfs units are
loaded, fds whose target unit is not (yet) known are not dropped: they
are stashed in a new luo_held_fds hashmap keyed by cgroup path. They are
re-tried in two places: after deserialization, and from unit_load(), so
fds land in the correct fd store as soon as the owning unit is parsed,
allowing units to be plugged in at runtime.
Non-kexec shutdown paths are unaffected: if MANAGER_KEXEC is not the
final objective, no serialization file is produced and no LUO session is
ever created. Likewise if /dev/liveupdate does not exist, nothing
happens.
The LUO session creation is performed by systemd-shutdown, rather than
by PID 1, deliberately: it is the last point where we can be sure all
other processes have already been killed, so nothing else can race us
into creating (or worse, hijacking) the "systemd" session.
/dev/liveupdate is a singleton and session names are global. In
addition, any kernel-visible side effects of preserving objects (memory
pinning, etc.) are delayed until the absolute last moment, minimizing
the window in which they could affect the running system. There is no
behaviour change for shutdown paths other than kexec, or for kexec when
systemd didn't hand over a serialization fd (e.g. because no service had
any fds stored, or because LUO wasn't supported at serialization time).
Finally, since LUO sessions cannot be nested under other sessions,
third-party sessions need to be handled explicitly and held open in the
shutdown binary alongside our own internal session, to allow services to
create and preserve their own sessions. The requirement comes from VMMs
that wish to preserve VM state across kexec: some file descriptors (e.g.
KVM's vmfd from the KVM_CREATE_VM ioctl) cannot be transferred between
processes via SCM_RIGHTS, so they cannot be stashed in the FD Store
directly. Additionally, some file descriptors must be handled
all-or-nothing, again tied to KVM, where a VM and its associated devices
are one indivisible group.
https://docs.kernel.org/userspace-api/liveupdate.htmlhttps://docs.kernel.org/core-api/liveupdate.htmlhttps://docs.kernel.org/admin-guide/mm/kho.html
LUO sessions cannot be nested under other sessions. This means we need
to handle them explicitly, and held them open in the shutdown binary
like we do with our own internal session, to allow services to create
their own.
The requirement to support third party sessions comes from VMMs that
wish to preserve VM(s) state(s) across kexec, as some file descriptors
(KVM's vmfd from the KVM_CREATE_VM ioctl) cannot be transfered between
processes via SCM_RIGHTS, so they cannot be stashed in the FD Store
directly. Also some file descriptors have to be handled all together or
not at all, again to do with KVM and devices that are all part of the
same vm.
Wires up the systemd-shutdown side of the kexec-via-LUO fd store preservation.
When rebooting via kexec, systemd builds a JSON description of the fd
stores of all loaded services and passes it to systemd-shutdown through
the SYSTEMD_LUO_SERIALIZE_FD environment variable. The FDs themselves
come in as part of the normal shutdown FDSet. systemd-shutdown's job is
then, at the very last moment before invoking the kexec syscall, to
move that state into a kernel LUO session so it survives the reboot.
Doing the LUO session creation here, rather than in PID 1, is
deliberate:
* It's the last point where we can be sure all other processes have
already been killed, so nothing else can race us into creating (or
worse, hijacking) the "systemd" session, as /dev/liveupdate is a
singleton and a session name is global.
* Any kernel-visible side effects of preserving objects (memory
pinning etc.) are delayed until the absolute last moment, minimizing
the window in which they could affect the running system
No behaviour change for shutdown paths other than kexec, or for kexec
when systemd didn't hand over a serialization fd (e.g. because no
service had any fds stored, or because LUO wasn't supported at
serialization time).
The kernel Live Update Orchestrator (LUO) exposes /dev/liveupdate, which
allows userspace to hand a set of "preservable" kernel objects to the
new kernel across a kexec-based reboot. For now it only supports memfds,
with more object types (virtio devices, etc.) expected to be added later.
This is a natural fit for systemd's FD Store feature: services hand
memfds (containing serialized state or other service data) to PID 1 via
FDSTORE=1 sd_notify() messages, and get them back on their next start.
Today this works across service restarts, soft reboots and
initrd→rootfs transitions. With LUO we can extend the same mechanism to
work across kexec, too.
The protocol on the PID 1 side works roughly as follows:
* All preservable fds are collected into a single LUO session named
"systemd". Each FD gets uploaded with a token. Token 0 in that session
is reserved for a "mapping" memfd, which carries a JSON object
describing how to dispatch the other tokens back to units on the next
boot:
{
"foo.service": [
{ "type": "fd", "name": "stateA", "token": 1 },
{ "type": "fd", "name": "stateB", "token": 2 }
],
...
}
unit IDs are used as the unit identifier, as they're stable
across daemon-reexec, switch-root and kexec. token refers to the
LUO token assigned to the object in the session.
* On shutdown for MANAGER_KEXEC, just before manager_free(), systemd
walks all services and serializes their persistent fd store contents
(fds + FDNAMEs + unit IDs) into a JSON memfd. The FDs themselves are
gathered into a FDSet to be kept around. The fdset and the
serialization memfd are passed to systemd-shutdown via the
SYSTEMD_LUO_SERIALIZE_FD environment variable providing the fd number,
so the actual LUO session creation and ioctls can happen as the very
last step before kexec (shutdown implementation is the next commit).
* On boot, manager_luo_restore_fd_stores() opens /dev/liveupdate,
tries to retrieve the "systemd" session, reads the mapping memfd,
then for each entry retrieves the fd from the session and attempts
to attach it to the matching unit's fd store.
* The FDs are injected in the appropriate unit's FD stores using the
same mechanism as the LISTEN_FDS propagation that was set up earlier.
Non-kexec shutdown paths are unaffected: if MANAGER_KEXEC is not the
final objective, no serialization file is produced and no LUO session
is ever created. Likewise if /dev/liveupdate does not exist, nothing
happens.
When there is a NOTIFY_SOCKET, and FDs are received from the
payload following the FD Store protocol, forward them up the
chain to the service manager that is managing nspawn.
This allows FD Store persistence across container restarts,
and can chain up for user managers as well to survive restarting
those, or reexecs, and in the future reboots too via LUO.
Add a new test case to exercise the PID1 -> user session -> nspawn -> payload
chain.
In order to allow FD Stores of user units to survive a user
session restart, propagate FDs received via the protocol up one
level from user to system manager via sd_notify.
And the other way around, propagate them down via LISTEN_FDS
tagging them with the unit name so that the child manager can
inject them in the appropriate unit.
Ensure units that are dead or not loaded can get FDs added to
their stores, and that they are correctly propagated once the
unit is started or loaded. When the unit is not loaded we don't
know what the FD max limit is, so simply increase it for each FD
injected, and then when the unit is realised prune it down to
match the unit's now available config in case the limit is lower
than the number of FDs in the store.
Each FD sent up or down is assigned a monotonic index, and the manager
also sends a JSON map that associates the index with the original
unit and FDNAME:
{
"unit-name.service": [
{ "name": "fdname1", "index": 1 },
{ "name": "fdname2", "index": 2 }
],
...
}
This allows the manager to assign back the FDs to the appropriate
unit using the appropriate name, given the FDNAMEs are not unique.
This PR adds some more properties to the io.systemd.Unit.StartTransient
varlink interface: WorkingDirectory, Environment and
SetCredential{,Encrypted}. Its also hopefully a useful starting point to
establish a pattern to add even more.
We want to reopen the console used for logging when running as PID1, but
also when running a user manager (c.f. 48a601fe5d
and 2a646b1d62). But this can cause
problems when the binary is invoked directly, e.g. to print --help.
E.g. if we ignore SIGPIPE, we'd remain running briefly after
'/usr/lib/systemd/systemd --help | head -n1'.
Previusly, the getopt machinery would print to stderr unconditionally.
But after the rework of option parsing, which means that we use the
log_* functions to repor errors, the test that checks if we print errors
to stderr started failing.
So let's skip some more of the setup if !invoked_by_systemd().
This function is used in a quite a few places and it calls getenv and
does a bit of parsing, so let's try to speed this up.
Also, mark it _const_. With the caching, it now always returns the same
result, so we can tell the compiler to eliminate subsequent invocations.
It'd be nice if we could not repeat the information about the option
list a second time. But I don't see a nice way to do this, since
(by design) with the macro approach, the macros must be intertwined
with the parse_argv() code. But that code in turn refers to a bunch
of variables, so lifting out the function is not immediately possible.
So I think it's best to keep the existing approach where we provide
a list of options, without additional context, and skip them using
a custom routine.
099663ff8c added "support" for
-b/-s/-z ARG with a comment of
> /* Just to eat away the sysvinit kernel cmdline args without getopt()
> * error messages that we'll parse in parse_proc_cmdline_word() or
> * ignore. */
And for PID1 those was valid. But when not running as PID1, those
options would be parsed as valid but then help() would immediately
return -EINVAL:
$ build-old/systemd -b; echo $?
1
At the same time, when running as PID1, if we encounter an error,
we shouldn't opine about the rest of the command line. So continuing
with the loop and the checks after the loop were iffy.
Later, cd57038a30 made a big refactoring,
and the 'break' (i.e. continuation of the loop) was changed to 'return 0',
making things even more confusing, since now we'd just silently stop in
the middle of the command line if -b/-s/-z were encountered.
So be more careful: when running as PID1, stop parsing on error
and return from the function. We didn't parse the full command line,
so the later checks are not useful. Silently ignore -b/-s/-z.
When not running as PID1, explicitly say that -b/-s/-z are not
supported, and propogate the error if parsing fails, e.g. with
an unknown option.
parse_argv() uses FOREACH_OPTION (not _OR_RETURN) so we can preserve the
existing PID 1 tolerance: an unknown option, or one of the sysvinit-style
-b/-s/-z catch-alls, returns 0 instead of -EINVAL when getpid_cached() == 1.
The docs documented --crash-vt=, but the code implemented "crash-chvt",
as introduced in b9e74c3994.
The output from --help is now modified to match code.
getopt-defs.h is intentionally left in place since
proc_cmdline_filter_pid1_args() in src/basic/proc-cmdline.c still uses
its COMMON_/SYSTEMD_/SHUTDOWN_GETOPT_* macros to walk the kernel
command line.
Previously, opterr=0 was used to suppress error messages about option
parsing in PID1. They are now logged at debug level (if debug logging
is enabled.)
Co-developed-by: Claude Opus 4.7 <noreply@anthropic.com>
Add exec_command_status_build_json() and exec_command_status_list_build_json() to varlink-common, alongside exec_command_build_json() and exec_command_list_build_json(). The status list function is the runtime counterpart of the command list function — the two arrays are positionally aligned so index N in the status array corresponds to index N in the command array. Commands that have not yet run produce null entries to preserve alignment.
Add the ExecCommandStatus varlink struct type to varlink-idl-common next to ExecCommand. It contains PID, timestamps, and mutually exclusive ExitStatus (int, for normal exit) / ExitSignal (string, for signal kill).
