[code sync] Merge code from sonic-net/sonic-host-services:202605 to 202608 - #18
Merged
Merged
Conversation
mssonicbld
commented
Aug 6, 2026
mssonicbld
commented
Collaborator
…en gnmi is masked (#420) #### Why I did it Fixes sonic-net/sonic-buildimage#28387 `gnoi-shutdown.service` declared `Requires=gnmi.service`, but `gnmi` is a delayed feature that is masked at boot until `featured` starts it after `PortInitDone`. With a hard `Requires=` on a masked unit, systemd refuses the gnoi-shutdown start job and never evaluates the unit's `ExecCondition`, leaving `ConditionTimestampMonotonic=0` and `Result=success`. `healthd` (system-health `sysmonitor`) cannot distinguish this from a genuinely un-started service, so it reports `gnoi-shutdown` as `Inactive` and never publishes `SYSTEM_READY|SYSTEM_STATE Status=UP`. `hsflowd` then waits for that key (or its 180s fallback), so sFlow / drop-monitor is unavailable for ~3 minutes after every start. The inline `ExecCondition` added in #395 cannot help, because the start job never reaches the condition. Reproduced on non-SmartSwitch `x86_64-mlnx_msn4700-r0` / `msn2700a1-r0` and SmartSwitch `x86_64-nvidia_sn4280-r0`. #### How I did it Move `gnmi.service` from `Requires=` to `Wants=` in `data/debian/sonic-host-services-data.gnoi-shutdown.service`, keeping `After=...gnmi.service...` for ordering. - **Non-SmartSwitch:** a masked `gnmi` is now tolerated, so the start job proceeds and the `ExecCondition` runs and exits non-zero -> `Result=exec-condition`, `ConditionResult=no`, nonzero `ConditionTimestampMonotonic`. healthd treats it as a non-blocking platform skip. - **SmartSwitch NPU:** `ExecCondition` exits 0 and the daemon starts and listens on STATE/CONFIG_DB. It only needs `gnmi` at DPU-shutdown time (`docker exec gnmi gnoi_client ...`), which is long after `gnmi` is up, so starting early is safe and avoids missing early events. - `After=` still orders gnoi-shutdown after gnmi whenever gnmi is actually pulled into the transaction (i.e. when it is not masked). #### How to verify it On a non-SmartSwitch Mellanox platform (e.g. msn2700) with a fresh 202605 image: 1. Boot and wait for `featured` to start the delayed `gnmi`. 2. `systemctl show gnoi-shutdown -p ActiveState -p SubState -p Result -p ConditionResult -p ConditionTimestampMonotonic` - Expect `Result=exec-condition`, `ConditionResult=no`, and a **nonzero** `ConditionTimestampMonotonic` (previously `Result=success`, ts `0`). 3. `sysreadyshow --detail` and `redis-cli -n 6 HGET 'SYSTEM_READY|SYSTEM_STATE' Status` -> `UP`. 4. `redis-cli -n 6 HGETALL 'ALL_SERVICE_STATUS|gnoi-shutdown'` -> no longer blocking. 5. Confirm hsflowd no longer waits the 180s fallback before sFlow samples flow. On a SmartSwitch NPU (sn4280): confirm `gnoi-shutdown` is active after boot and a DPU `admin_status=down` still triggers the gNOI HALT sequence. #### Verification results (hardware, 202605, mellanox) Reproduced the regression and validated the fix on two SKUs. The delayed `gnmi` feature was masked to recreate the exact boot-time condition, then only `Requires=`->`Wants=` was changed: SmartSwitch NPU `x86_64-nvidia_sn4280-r0` (gnoi-shutdown is applicable): - Before (`Requires=gnmi.service`, gnmi masked): `systemctl start gnoi-shutdown` -> `Failed to start gnoi-shutdown.service: Unit gnmi.service is masked.`; unit stays `inactive/dead`. - After (`Wants=gnmi.service`, gnmi still masked): start succeeds -> `active/running`; the platform `ExecCondition` is evaluated (nonzero `ConditionTimestampMonotonic`). Non-SmartSwitch `Mellanox-SN2700` (gnoi-shutdown is inapplicable): - Before (`Requires=gnmi.service`, gnmi masked): `Failed to start ... Unit gnmi.service is masked.`; healthd `ALL_SERVICE_STATUS|gnoi-shutdown = Down` and `SYSTEM_READY|SYSTEM_STATE = DOWN`. - After (`Wants=gnmi.service`, gnmi still masked): start succeeds and the `ExecCondition` now runs and cleanly skips the service -> `Result=exec-condition`, `ConditionResult=no`; healthd `ALL_SERVICE_STATUS|gnoi-shutdown = OK` (non-blocking via `NON_BLOCKING_INACTIVE_REASONS={"exec-condition"}`). In both cases the only change was `Requires=`->`Wants=`, which lets the start job proceed while `gnmi` is masked so the platform `ExecCondition` actually runs. #### Which release branch to backport (provide reason below if selected) - [x] 202605 Reason: boot-time readiness regression introduced in 202605 (via #343 / #395); it blocks `SYSTEM_READY` and delays sFlow on Mellanox SmartSwitch and non-SmartSwitch platforms. #### Description for the changelog [gnoi-shutdown] Use Wants= instead of Requires= for gnmi.service so the platform ExecCondition runs when gnmi is a masked delayed feature, unblocking SYSTEM_READY. Signed-off-by: Sonic Build Admin <sonicbld@microsoft.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.