k8snetworkplumbingwg / multus-cni / 39209624369
55%
master: 55%

LAST BUILD BRANCH: dra_new_feature
DEFAULT BRANCH: master
Ran
Jobs 1
Files 28
Run time 1min
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst
coverage: 54.669% (+0.02%) from 54.645%
39209624369

Pull #1564

github

oshoval 
server: don't unlink the socket file on listener close

Go's unix listener created by net.Listen unlinks its socket path when
the listener is closed. With the graceful-termination delay introduced
in v4.3.1 (SigTermCancelAfter = 10s), an old daemon can still be
shutting down while its successor has already recreated the socket at
the same path. When the old listener finally closes, Go unlinks the
path and deletes the successor's live socket file. The new daemon keeps
listening on an orphaned inode and clients can no longer connect to
/run/multus/multus.sock.

Disable the implicit unlink-on-close with SetUnlinkOnClose(false). This
is safe because startup cleanup is already handled by
FilesystemPreRequirements, which removes the whole socket directory
before every listen, so no stale socket files are left behind.

Verified on a k8s-1.36 kubevirtci cluster with CNAO's "deploy all
components at once" + "deploy all components one by one" spec pair:
without the fix the successor's socket file is deleted ~6s after
creation and multus-dynamic-networks-controller probes fail with
`curl: (7)` forever; with the fix both specs pass and the healthz
endpoint answers 200 from inside client pods throughout.

Assisted-by: GLM 5.3
Signed-off-by: Or Shoval <oshoval@redhat.com>
Pull Request #1564: server: don't unlink the socket file on listener close

3009 of 5504 relevant lines covered (54.67%)

7.06 hits per line

Coverage Regressions

Lines Coverage ∆ File
128
49.25
0.26% pkg/server/server.go
Jobs
ID Job ID Ran Files Coverage
1 Go- - 39209624369.1 28
54.67
GitHub Action Run
Source Files on build 39209624369