[202405] Fix race condition between featured daemon-reload and docker container start on chassis#388
Open
arista-setu wants to merge 1 commit into
Conversation
… start Following procedure during boot causes suprious issue: - the featured daemon loops through every feature and for each one writes a systemd config file, calls systemctl daemon-reload (which temporarily tears down cgroup directories), - Next, docker container start — but the container started in the previous iteration may still be initializing - Here when daemon-reload fires for the next feature, it destroys the group path that the previous container's runc process is trying to write its PID to, resulting in the "no such device" error. The fix splits this boot-time loop into two phases: - first write all systemd config files and do a single daemon-reload, - Secondly start all the containers Therefore, no daemon-reload can race against a container is starting up.
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
Hi, there are workflow run(s) waiting for approval, you may be first-time contributor. I will notify maintainers to help approve once PR is approved. Thanks! ---Powered by SONiC BuildBot
|
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
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.
Issue:
This PR proposes a fix for an open issue sonic-net/sonic-buildimage#20988 on 202405 branch for chassis
The underlying issue is seen only on chassis but it is rarely seen. It has been seen couple of times only and been not reproducible. I was not able unable to on our chassis as well. However, it seems like there exists a race condition between featured daemon-reload and docker container start process.
Based on current code review, following procedure during boot could have causes this issue:
The featured daemon loops through every feature and for each one writes a systemd config file, calls systemctl daemon-reload (which temporarily tears down cgroup directories)
Then, docker container starts
Here when daemon-reload fires for the next feature in loop ( here note that the container started in the previous iteration might still be initializing), it destroys the group path that the previous container's run process is trying to write its PID to, resulting in the "no such device" error.
https://github.com/sonic-net/sonic-host-services/blob/202405/scripts/featured#L227 > tiggers daemon-reload https://github.com/sonic-net/sonic-host-services/blob/202405/scripts/featured#L367
As a result, the docker start could fail as follow:
Proposed Fix:
The proposed fix will slightly change docker startup procedure. We could use 2 phase approach in sync_state_field : https://github.com/sonic-net/sonic-host-services/blob/202405/scripts/featured#L210) to avoid race condition between systemctl daemon-reload and Docker container startup:
Phase 1 - write all systemd config files and trigger a single daemon-reload after all config is written
Phase 2 - start all the containers
Testing:
The issue was not reproduced before this change during testing.
However, I've attempted 5-6 reboots on chassis with 202405 image with this particular change. The underlying issue was still not reproduces and no other side-effects of this change were seen. All docker containers started as expected.
Backport request:
A PR with same changes is create against master : #387
Since that PR cannot be backported cleanly, this PR is open to include the change in 202405
If/when this PR merges, I request sonic-host-services submodule bump-up at https://github.com/Azure/sonic-buildimage-msft/tree/202405/src