Most of the time, the CLI tools that will use this helper are dealing
with the string representation of log levels, so just add string-based
helpers for now.
We already have io.systemd.service.SetLogLevel. Add a getter so that
CLI tools with `log-level` subcommands can be more easily implemented
with varlink.
Bind this method to all services that already bind io.systemd.service.SetLogLevel.
Add varlink version of FlushCaches.
Add this to io.systemd.Resolve.Monitor, since that interface already
handles many cache and manager related things.
In Ubuntu, rsyslog is (a) part of the minimal image and (b) does not run
as root. To facilitate this, the rsyslog package configures /var/log
to be writeable by the syslog group.
There are currently conflicts in the Ubuntu packaging due to the way
tmpfiles are handled in package scripts: when systemd-tmpfiles is
invoked with both configurations (or for all configurations), things
work fine. But if invoked with only var.conf, which is the default case
for package upgrades, rsyslog is broken.
One suggestion to approach this was to make rsyslog's tmpfile
configuration use ACLs instead of trying to change the owning group and
directory mode. This can work, but since the ACL mask is stored in the
group permission bits, the effective mask for rsyslog becomes r-x again
when var.conf is invoked, because it sees that 0775 != 0755, and chmods
the directory.
Hence, for /var/log write permisssions to be extendable with ACLs,
the mode must be at least 0775. Rather than change the default,
add a build option to configure the /var/log mode.
This test never finishes in Ubuntu autopkgtest with the current values,
and is currently skipped all together on Debian. When running on either,
reduce the number of disks to make the test more reliable.
This is preparation for using varlink methods more in resolvectl. In
particular, this is helpful for proving more accurate error messages,
and maintaining compatibility with existing error messages from the
DBus API.
Generalize json_dispatch_address from nss-resolve, and add support for
strings to be compatible with the existing json_dispatch_{in,in6}_addr
helpers. This will be used in a later commit.
There are several places where address family is dispatched from JSON,
so take json_dispatch_address_family from networkd and put it in
json-util.c.
Update the all instances in the tree to use this new function, adding
SD_JSON_RELAX to the dispatch flags if AF_UNSPEC should be allowed
in that case.
The have_updatectl variable is meant to gracefully handle the case where
updatectl is missing. But, because the script runs with -e, it fails
immediately in that case instead. Moreover, expanding $have_updatectl
when it is present actually executes updatectl, rather than simply
checking for its existence.
Re-factor this check so that it does handle a missing updatectl.
Without this, the socket is available well before systemd-networkd.service
is able to start, because of its own After=network-pre.target ordering.
Then, if resolved handles queries before network-pre.target, it will
hang waiting for networkd to reply to hook queries.
This is currently happening in the wild with cloud-init.
Using the format specifier +%s%6N with GNU date is honored, and only
prints 6 digits of the nanoseconds portion of the seconds since epoch.
The uutils implementation of date does not honor this, and always prints
all 9 digits. This is a known bug[1], but can be worked around by
adapting this test to use nanoseconds instead of microseconds.
[1] https://github.com/uutils/coreutils/issues/11658
The network generator currently supports many of the options described
by dracut.cmdline(7), but not everything.
This commit adds support for the BOOTIF= option (and the related
rd.bootif= option) used in PXE setups.
This is implemented by treating BOOTIF as a special name/placeholder
when used as an interface name, and expecting a MAC address to be set in
the BOOTIF= parameter. The resulting .network file then uses MACAddress=
in the [Match] section, instead of Name=.
It has been observed on some systems[1] that ssh-issue may print out:
Try contacting this VM's SSH server via 'ssh vsock%4294967295' from host.
i.e. it suggests connecting with VMADDR_CID_ANY, which is not valid. It
seems that IOCTL_VM_SOCKETS_GET_LOCAL_CID may return VMADDR_CID_ANY in
some cases, e.g. when vsock is not full initialized or so.
Treat VMADDR_CID_ANY as special in vsock_get_local_cid(), the same as
VMADDR_CID_LOCAL and VMADDR_CID_HOST, and return an error.
[1] https://launchpad.net/bugs/2145027
Right now, if a user tries to pass VMADDR_CID_ANY to systemd-ssh-proxy,
an assert is triggered:
$ ssh vsock%4294967295
Assertion 'cid != VMADDR_CID_ANY' failed at src/ssh-generator/ssh-proxy.c:21, function process_vsock_cid(). Aborting.
mm_receive_fd: recvmsg: expected received 1 got 0
proxy dialer did not pass back a connection
This is becauase the value returned from vsock_parse_cid is not checked
before being passed to process_vsock_string. Add a check to prevent
that.
These syscalls are part of a newer kernel API to replace interaction
with /proc/self/attr, with the goal of allowing LSM stacking. These are
being used now by e.g. libapparmor, so should be more easily available
to services using seccomp filtering.
Historically, resolvectl status has not included the interface
specification for DNS servers with an IPv6 link-local address, since it
is technically somewhat redundant. But, adding this extra bit of
information makes it easier to copy-and-paste to use elsewhere, etc.
For example, the previous output:
Link 2 (enp34s0)
Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
Protocols: +DefaultRoute LLMNR=resolve -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: fe80::861e:a3ff:feb1:f8e7
DNS Servers: 192.168.1.12 192.168.1.13 fe80::861e:a3ff:feb1:f8e7
DNS Domain: lan
now becomes:
Link 2 (enp34s0)
Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
Protocols: +DefaultRoute LLMNR=resolve -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: fe80::861e:a3ff:feb1:f8e7%2
DNS Servers: 192.168.1.12 192.168.1.13 fe80::861e:a3ff:feb1:f8e7%2
DNS Domain: lan
There is a lot of duplication across the functions for printing global,
link, and delegate output. Since these all use a common DNSConfiguration
type now, the logic can be consolidated.
Adapt printing and format helper functions to accept a DNSConfiguration
parameter to appropriately format output. Then, add print_configuration(),
a single function that prints the appropriate status output based on the
contents of DNSConfiguration.
Now that varlink is always used for status output, consolidate the JSON
and regular status code paths. Add status_full(), which is the single
point that calls DumpDNSConfiguration, filters based on link names and
mode if needed, and prints the output in the appropriate format.
This simplifies status_ifindex(), and removes the need for a separate
status_json().
This is an incremental commit to replacing dbus usage with varlink for
all status output.
Re-implement regular delegate status output using the DumpDNSConfiguration
varlink method. And, remove the DelegateInfo type and associated functions
which were used to map dbus properties.
Since this is the last type of status output to be switched to varlink,
lots of other code becomes dead with these changes, e.g.
read_dns_server_one(), map_dns_servers_internal(), etc., so remove those
too. Finally, status_all() no longer needs sd_bus, so drop that
parameter.
This is an incremental commit to replacing dbus usage with varlink for
all status output.
Re-implement regular link status output using the DumpDNSConfiguration
varlink method. And, remove the LinkInfo type and associated functions
which were used to map dbus properties.
This is an incremental commit to replacing dbus usage with varlink for
all status output.
Re-implement regular global status output using the DumpDNSConfiguration
varlink method. And, remove the GlobalInfo type and associated functions
which were used to map dbus properties.
This only has a small effect, which mostly matters for generating status
output. It ensures that the order of servers and domains displayed
matches the order they are stored on the daemon side, which keeps the
new resolvectl output consistent with the old.
This is one of several commits to dispatch all fields of the
DNSConfiguration JSON.
Introduce a DNSScope type, and all required JSON dispatching helpers.
The varlink API is currently missing the "DNSSEC supported" field, which
is required for to re-implement the existing resolvectl status output
with varlink instead of dbus.
Add this field to DNSConfiguration.
Partially reverts d6b3793704.
On Ubuntu 26.04 devel, TEST-75-RESOLVED often fails at this stage,
despite the matching query apparently being found:
+ monitor_check_rr '2025-12-18 16:02:54' 'follow10.so.close.signed.test IN CNAME follow11.yet.so.far.signed.test'
+ set +x
Dec 18 16:02:54 ns1.unsigned.test resolvectl[552]: ← A: follow10.so.close.signed.test IN CNAME follow11.yet.so.far.signed.test
+ monitor_check_rr '2025-12-18 16:02:54' 'follow11.yet.so.far.signed.test IN CNAME follow12.getting.hot.signed.test'
+ set +x
Dec 18 16:02:54 ns1.unsigned.test resolvectl[552]: ← A: follow11.yet.so.far.signed.test IN CNAME follow12.getting.hot.signed.test
+ monitor_check_rr '2025-12-18 16:02:54' 'follow12.getting.hot.signed.test IN CNAME follow13.almost.final.signed.test'
+ set +x
Dec 18 16:02:54 ns1.unsigned.test resolvectl[552]: ← A: follow12.getting.hot.signed.test IN CNAME follow13.almost.final.signed.test
+ monitor_check_rr '2025-12-18 16:02:54' 'follow13.almost.final.signed.test IN CNAME follow14.final.signed.test'
+ set +x
Dec 18 16:02:54 ns1.unsigned.test resolvectl[552]: ← A: follow13.almost.final.signed.test IN CNAME follow14.final.signed.test
Unsetting pipefail, as was done before d6b3793704, appears to fix the
problem.
With GNU coreutils, one can pass an argument to the "set" flag like:
date -s "-3 days"
With uutils coreutils, that gives an error:
error: unexpected argument '-3' found
tip: to pass '-3' as a value, use '-- -3'
That's a bug (https://github.com/uutils/coreutils/issues/9679), but both
implementations accept --set="-3 days" just fine, so use that instead.
On Ubuntu's test infrastructure for the development series, this test
often fails when piping the journal output to head. The cause is
unclear, but possibly related to Ubuntu's use of uutils coreutils.
Workaround this by just using journalctl's -n flag, which removes the
need for piping output to head.
The current_dns_server_json object in dns_configuration_json_append() is
always NULL, because the logic to dump the current DNS server to JSON
was removed by mistake in a re-factoring commit. Add that logic back.
Fixes c6b6ac63ea ("resolve: drop unnecessary preparation of empty arrays").
The qemu update migrated to noble-updates a couple weeks ago, so it is
no longer necessary to enable noble-proposed (or add the associated apt
pinning config).
The primary motivation for this is to allow users of ukify to build
UKI-like objects, without having them later be detected as a UKI by
tools like kernel-install and bootctl.
The common code used by these tools to determine if a PE binary is a UKI
checks that both .osrel and .linux sections are present. Hence, adding
a mechansim to skip .osrel provides a way to avoid being labeled a UKI.
This is also temporary, but demonstrates that the version of qemu
currently in noble-proposed fixes https://launchpad.net/bugs/2127974,
which will ultimately allow for the fix to be released to noble-updates.
Right now, this test runs inside unprivileged chroots, despite the
running_in_chroot() check. This is because running_in_chroot() fails
with -EACCES, which is ignored.
Hence, check for privileges before calling running_in_chroot(),
otherwise call is inconclusive. Note, the test will fail later on if
running without privileges anyways.
Do not set a timeout on the wait-online call, since there are timeout
calls later that will prevent the test from blocking forever. Increase
those timeout calls for slower CI runs.
The current test is flaky because it creates a new interface definition,
calls networkctl reload, and then calls resolvectl show-cache. If
resolved has not received the changes and setup the DNS scopes for the
interface, show-cache will be empty for that interface.
Part 2 of #39602
Add io.systemd.Resolve.DumpDNSConfiguration. This provides the same
information as io.systemd.Resolve.Monitor.SubscribeDNSConfiguration,
but just returns the configuration once without the subscription logic.
In order to use the same definitions for DNSConfiguration et al. between
both interfaces, move the definitions to io.systemd.Resolve, and include
them in io.systemd.Resolve.Monitor.
This will be used to implement --json for resolvectl status.
The io.systemd.Resolve.Monitor.DNSConfiguration type is being expanded,
but we do not need the extra information for determining online status.
Ignore these fields when dispatching JSON to avoid "Unrecognized object field"
messages adding noise to systemd-networkd-wait-online debug output.
Although the JSON output is mostly intended to be machine readable,
humans also consume the output through logs and scripts.
Add an addressString field to DNSServer to improve human-readability.
Depending on the packaging of tzdata, /usr/share/zoneinfo/tzdata.zi may
reference zones or links that are not actually present on the system.
E.g. on Debian and Ubuntu, there is a tzdata-legacy package that
contains "legacy" zones and links, but they are still referenced in
/usr/share/zoneinfo/tzdata.zi shipped by the main tzdata package.
Right now, get_timezoes() does not validate timezones when building the
list, which makes the following possible:
$ timedatectl list-timezones | grep "US/Alaska"
US/Alaska
$ timedatectl set-timezone US/Alaska
Failed to set time zone: Invalid or not installed time zone 'US/Alaska'
which feels buggy. Hence, simply validate timezones in get_timezones()
to avoid listing timezones that are not installed.
There are a lot of resolved.conf.d drop-ins used in these tests. Use
proper numeric prefixes, especially to avoid confusion with sorting
relative to test.conf.
Make the test base config 10-test.conf, and use 90-*.conf elsewhere.
On reload, resolved does not apply new DNSSEC= (or DNSOverTLS=) settings
on links, because the link unicast scopes are not re-created. However,
the servers and link states are updated correctly, so resolvectl and link
state files do show the new setting, leading users to believe the change
took effect immediately, the same way `resolvectl dnssec` does.
Fix this by freeing all of the link unicast scopes during reload, so
that they are re-created with the new settings in link_allocate_scopes().
Specifically, add a test case that ensures systemd-networkd-wait-online --dns
is robust against (a) systemd-resolved absence, and (b) systemd-resolved
restarts.
Now that systemd-resolved has socket activation for it's varlink
sockets, this should should be enough to make the DNS configuration
logic robust against systemd-resolved stops and restarts.
Add two new socket units, one for each of systemd-resolved's varlink
servers:
systemd-resolved-varlink.socket
systemd-resolved-monitor.socket
Add logic to grab socket fds via sd_varlink_server_listen_name(), but
fallback to the existing sd_varlink_server_listen_address() calls if no
fds were given.
This will be used to make systemd-networkd-wait-online --dns more robust
against systemd-resolved restarts etc.
Commit 536c18e5c3 ("bus-polkit: shortcut auth. after first denial")
added logic to async_polkit_query_check_action() that returns
-EALREADY when a failure or denial decision was made for a previous
action.
Tweak this to return -EBUSY instead of -EALREADY. This hopefully makes
the intent of the error more clear. EALREADY suggests that the request
is OK, but polkit is processing something else, and we should come back
later. EBUSY suggests that polkit is busy or unusable, hence the
request cannot be processed, and we should go away.
The semantics of strong inhibitors require that POLKIT_ALWAYS_QUERY
always be set when checking if we can allow blocking inhibitors to be
ignored on shutdown, reboot, etc. With the default polkit rules and
policy, users may experience a situation where users in the sudo group
are authorized to run:
systemctl reboot --check-inhibitors=no
but the root user is not authorized. Instead, the following error is
given:
Call to Reboot failed: Interactive authentication required.
While this is correct according to the semantics of strong inhibitors,
it is confusing. To help the situation, provide example polkit rules
that allow root to perform these actions.
Finally, when root receives SD_BUS_ERROR_INTERACTIVE_AUTHORIZATION_REQUIRED
when calling e.g. systemctl reboot, print a message explaining that this
is due to the current polkit policy, and point to the new example rule.
Related: https://github.com/systemd/systemd/issues/36786
Commit 536c18e5c3 ("bus-polkit: shortcut auth. after first denial")
added logic to async_polkit_query_check_action() that returns
-EALREADY when a failure or denial decision was made for a previous
action.
This has the consequence that root is able to ignore inhibitors and
shutdown etc. even when polkit explicitly denies it. This is because
when systemctl's verb_start_special() calls logind_reboot(), unless
the call succeeds or returns one of -EACCES, -EOPNOTSUPP, or
-EINPROGRESS, a fallback path is taken to attempt the action without
going through logind. Hence, since logind_reboot() started returning
-EALREADY in some cases, the fallback path was taken, and the shutdown
was performed anyways.
For example:
root@ubuntu:/# cat /etc/polkit-1/rules.d/10-systemd-logind-no-skip-inhibitors.rules
// Never allow strong inhibitors to be ignored.
polkit.addRule(function(action, subject) {
if ((action.id == "org.freedesktop.login1.power-off-ignore-inhibit" ||
action.id == "org.freedesktop.login1.reboot-ignore-inhibit" ||
action.id == "org.freedesktop.login1.halt-ignore-inhibit" ||
action.id == "org.freedesktop.login1.suspend-ignore-inhibit" ||
action.id == "org.freedesktop.login1.hibernate-ignore-inhibit")) {
return polkit.Result.NO;
}
});
root@ubuntu:/# systemctl reboot -i
Call to Reboot failed: Operation already in progress
..but the reboot continues anyways due to the fallback.
To fix this, add logic in systemd-logind's verify_shutdown_creds() to
handle -EALREADY from bus_verify_polkit_async_full(): if we receive
-EALREADY when checking authorization for <action>-multiple-sessions,
and we are blocked on inhibitors, continue on to get the decision for
<action>-ignore-inhibit directly.
While here, add similar logic to method_inhibit(), which may need to
verify multiple polkit actions in a single call.
Fixes 536c18e5c3
Add a new flag to systemd-networkd-wait-online, --dns, to allow waiting
for DNS to be configured.
DNS is considered configured when at least one DNS server is accessible.
If a link has the property DefaultRoute=yes (either by explicit
configuration, or because there are no routing-only domains), or if the
search domain '.' is configured, wait for link-specific DNS to be
configured. Otherwise, global DNS servers may be considered.
Add a new method to io.systemd.Resolve.Monitor that allows subscribing
to changes in the systemd-resolved DNS configuration. The new method
emits the full DNS configuration (one entry for global configuration,
and one entry for each interface), any time the configuration is
updated.
Take some of the same rule structure from 60-persistent-input.rules, and
apply it to hidraw devices in 60-persistent-hidraw.rules.
Since one of the motivations for this is being able to easily reference
FIDO tokens, add a special case when ID_FIDO_TOKEN==1, and add 'fido'
to the symlink.
The dbus property getter for DefaultRoute does not simply check
link->default_route. Instead, if l->default_route is not explicitly
configured, it checks dns_scope_is_default_route(l->unicast_scope).
Add a link_get_default_route() helper with this logic so that it can be
used for consistency.
We check this by opening a UDP socket and attempting to connect. We do
not send any traffic on it, but this will tell us if there are routes to
the DNS server.
This will be used in a later commit.
No functional change. Make it more clear that these varlink connections
are subscribed to query results. This prepares for adding SubscribeDNS
to the varlink API.
TEST-75-RESOLVED fails on Ubuntu autopkgtest due to this warning from
knot:
notice: config, policy 'auto_rollover_nsec3' depends on default nsec3-salt-length=8, since version 3.5 the default becomes 0
Explicitly set nsec3-salt-length=8 to silence.
Currently, when SD_JSON_FORMAT_OFF is set in verb_call, the json format
flags are set to SD_JSON_FORMAT_PRETTY_AUTO|SD_JSON_FORMAT_COLOR_AUTO,
rather than or'ing those flags in. This means that other flags that may
have been set, e.g. SD_JSON_FORMAT_SEQ when --more is set, will be
clobbered.
Fix this by masking SD_JSON_FORMAT_OFF out, and then or'ing the new
flags in.
Nick Rosbrook