Yu Watanabe
736cb91535
Since the D-Bus DNS-SD API was introduced in c3036641f0ed (v236), `RegisterService()` has created an `sd_bus_track` object to destroy the registered service when the registering client disconnects from the bus. However, the track object is a `_cleanup_(sd_bus_track_unrefp)` local in `bus_method_register_service()` that is never stored anywhere, so it is destroyed again as soon as the method handler returns. The vanish handler (`dnssd_registered_service_on_bus_track()`) has thus been dead code for the past ~8 years. The observable effect: services registered via D-Bus silently persist after the client disconnects — unowned, advertised until resolved exits, and impossible to re-register since the identifier stays taken (`DNSSD_SERVICE_EXISTS`). At the same time, the registration doesn't survive a resolved restart, so the current behavior is neither reliably ephemeral nor reliably persistent. Noticed while reviewing a project that (unknowingly relying on this bug) registers a service with a one-shot `gdbus call` and expects it to persist. This PR: 1. splits the goodbye/zone-removal logic out of `bus_dnssd_method_unregister()` into a helper — the vanish path needs the full teardown, not just `dnssd_registered_service_free()`, which would leave the service's RRs published in the per-link mDNS zones; 2. stores the track object in `DnssdRegisteredService`, making client tracking work as originally intended; 3. documents the lifetime semantics in `org.freedesktop.resolve1(5)` (matching the equivalent Avahi D-Bus API, whose entry groups are likewise bound to the client connection) and points to `*.dnssd` files for registrations independent of a client's lifetime; 4. adds a TEST-75 case covering the connection-bound lifetime. Note this is a behavioral change for fire-and-forget clients (one-shot `busctl`/`gdbus` invocations). Arguably those were never working reliably (registrations silently vanished on any resolved restart, and stale entries blocked re-registration), but if this is deemed too risky, the alternative would be to drop the dead tracking code and codify the persist-until-exit behavior instead — I'd argue tracking as originally intended is the better contract. Verification: code compiles; the new integration test is included.
System and Service Manager
Details
Most documentation is available on systemd's website.
Assorted, older, general information about systemd can be found in the systemd Wiki.
Information about build requirements is provided in the README file.
Consult our NEWS file for information about what's new in the most recent systemd versions.
Please see the Code Map for information about this repository's layout and content.
Please see the Hacking guide for information on how to hack on systemd and test your modifications.
Please see our Contribution Guidelines for more information about filing GitHub Issues and posting GitHub Pull Requests.
When preparing patches for systemd, please follow our Coding Style Guidelines.
If you are looking for support, please contact our mailing list, join our IRC channel #systemd on libera.chat or Matrix channel
Stable branches with backported patches are available in the stable repo.
We have a security bug bounty program sponsored by the Sovereign Tech Fund hosted on YesWeHack
Repositories with distribution packages built from git main are available on OBS, and also repositories with packages built from the latest stable release