Add integration tests for the new ifindex=0 support
in BrowseServices that allows browsing all mDNS interfaces.
Integration test (in TEST-89-RESOLVED-MDNS.sh):
- testcase_browse_all_interfaces_ifindex_zero: Test with ifindex=0
Assisted-by: Claude Opus 4.5 (Preview)
Avahi provides AVAHI_IF_UNSPEC (-1) to browse mDNS services on all
interfaces simultaneously. Currently, systemd-resolved's BrowseServices
varlink API requires a specific interface index and lacks the ability to browse on
all available interfaces.
This change adds support for ifindex = 0 to mean \"browse on all mDNS-enabled
interfaces\" to match the Avahi API.
When ifindex = 0 is specified the browser will now iterate all mDNS scopes
instead of a single interface.
This enables applications to discover services on any network interface
without needing to know the specific interface index in advance.
Assisted-by: Claude Opus 4.6 (Eclipse Theia IDE AI)
The interface where each service was discovered needs to be remembered
so it can be correctly reported when the service is later removed.
Previously, service removal would use sb->ifindex, losing the actual
interface information from the original discovery.
This change:
- Adds an ifindex field to DnssdDiscoveredService struct
- Stores the discovered interface index when adding new services,
preferring the per-item ifindex from DnsAnswerItem over the service
browser's ifindex
- Uses the stored ifindex when reporting service removal events
This ensures that service removal notifications include the correct
interface index where the service was originally discovered, matching
the behavior of the corresponding service addition notifications.
Assisted-by: Claude Opus 4.6 (Eclipse Theia IDE AI)
The removed code in device_tag_index() in fact does nothing,
as sd_device.all_tags is never cleared. Moreover, not only the code
is meaningless, but it is theoretically/logically wrong, as the symlinks
in /run/udev/tags/ should be 'sticky', hence we should even not try to
remove them.
The current tag concept has been introduced by
e77b146f82 (v247) to make symlinks in
/run/udev/tags/ are 'sticky'.
However, when TAG= (rather than TAG+=) is specified, then the tags
assigned in the previous events were also cleared.
This fixes the issue and now symlinks in /run/udev/tags/ are really
'sticky'.
Fortunately, TAG= is mostly unused. So, the issue should not affect
and the fix should not change anything on almost all systems.
journalctl: add new varlink read service to get entries
We already have some varlink support for the journal to perform
some actions like `Rotate`. It would be nice to be able to query
the journal via varlink too so this commit adds a new varlinkctl
based journal service that exposes a single GetEntries() call
to retrieve journal entries. Basic filtering is supported and
we can expand the API as needed.
This is a separate `io.systemd.JournalControl` [1] service from the
existing `io.systemd.Journald` to decouple read and write (thanks
to Lennart for suggesting this).
This also extracts some shared helper so that we do not duplicate
code when generating the json or when adding the filters.
[1] The name mirrors the bootctl->io.systemd.BootControl naming.
ref_uid is initialized to invalid, and is only set in some
circumstances. The AttachProcesses will attempt to check it,
and assert that it is valid. Check beforehand.
Reported as YWH-PGM9780-89
Follow-up for 59857b672c
We already have some varlink support for the journal to perform
some actions like `Rotate`. It would be nice to be able to query
the journal via varlink too so this commit adds a new varlinkctl
based journal service that exposes a single GetEntries() call
to retrieve journal entries. Basic filtering is supported and
we can expand the API as needed.
This is a separate `io.systemd.JournalControl` [1] service from the
existing `io.systemd.Journald` to decouple read and write (thanks
to Lennart for suggesting this).
This also extracts some shared helper so that we do not duplicate
code when generating the json or when adding the filters.
[1] The name mirrors the bootctl->io.systemd.BootControl naming.
find_ovmf_config() would do filtering based on arg_secure_boot
already, hence the mismatch can only occur if we're using
user-specified firmware. So be explicit about this in log.
I expressed the issue I have with parse_tristate_argument()
in #37751: it doesn't add any value to direct use of parse_tristate();
on the contrary, it doesn't support means to reset the arg to "auto"/-1 state.
The mere reason it existed is that we need a int type ret param.
Since the previous attempt to address this mess failed, let's
try to make the function more useful by making it accept "auto".
I figure this is useful on its own.
As requested in
https://github.com/systemd/systemd/pull/40652#discussion_r2831833996,
the function name is suffixed with _with_auto() to establish
that "auto" is handled internally.
The CleanPool requires --more to be set and checks that in
`vl_method_clean_pool`. By switching to SD_VARLINK_REQUIRES_MORE
this will automatically be handled and is more clear to
the varlink users.
Based on the comment from Lennart in
https://github.com/systemd/systemd/pull/40650#discussion_r2832378002
and the work done by Mike in 09388a6b9e (thanks!).
Report DiskTooSmall only if partitions managed by repart don't fit the
disk. Because if the disk is already full with forigin partitions we
would always report DiskTooSmall instead of InsufficentFreeSpace.
To decide whether the disk is to small or has insufficient free space we
need to know how much of the disk is filled with foreign partitions.
The calculated size is used in a future commit.
When working on disks the disk may have a total size bigger then the
actual allocated size, therefore sum up the current partitions to
calculate the current disk size instead of asuming that the entire disk
is currently allocated.
The tool should not be considered stable, and those things we usually
place in /usr/lib/systemd, and not in $PATH.
We can move that to $PATH once we are confident it's gonna stay the way
it is.
Let's also rename the "metric_prefix" to "name", because it's actually
the servce name, and by giving it this generic name we can use it
reasonably in log messages.
Let's stay close to Varlink's naming rules and insist that metrics
prefixes must be valid varlink interface names, and suffixes are valid
varlink field names.
The former rule is clear: because a metric <x>.<y> can only be provided
by a varlink service <x>, it is obvious we should validate them the
same way. Validating the suffix via varlink field rules is not that
obvious, but I think it makes sense to stay close to Varlink naming
rules if we already started out at one place.
Let's prepare for a future where the "systemd-report" tool can do more
than enumerate metrics: let's introduce our usual "verbs" style
interface.
Let's also add a second command right-away: "describe-metrics" shows the
description of the metrics.
This makes the mstack_load() requires 'ret', as clearing the loaded
mstack without use is meaningless. All callers already pass non-NULL for
the argument.
Follow-up for 8343032a86.
Fixes CID#1645105.
In a way, metrics are a key-value concept, where the key is a triplet of
metrics family name, object name, and "fields". Let's put them together
in the varlink call, and put the value last, separately from that.
Also, update docs a bit, i.e be explicit about the metrics *family* name
everyhwere.
Christian Glombek
Yu Watanabe
Lennart Poettering
Luca Boccassi
Michael Vogt
Mike Yuan
Ryan Zeigler
David Santamaría Rogado
Antonio Alvarez Feijoo
Jim Spentzos
Julian Sparber