kube down: netavark: remove aardvark entries: failed to get aardvark pid: IO error (plus unmarshalling error)

[edsantiago]

[the unmarshalling part is obviously remote-only, I don't know about the nv/av part]

         not ok 427 |700| podman kube play healthcheck should wait initialDelaySeconds before updating status in 20579ms
...
<+013ms> # # podman-remote kube down /tmp/CI_MAGg/podman_bats.9Y3ZIj/play_kube_unhealthy_31Z2xs.yaml
<+0010s> # Error: unmarshalling into &types.PlayKubeReport{Pods:[]types.PlayKubePod(nil), Volumes:[]types.PlayKubeVolume(nil), PlayKubeTeardown:types.PlayKubeTeardown{StopReport:[]*types.PodStopReport{(*types.PodStopReport)(0xc00049a600)}, RmReport:[]*types.PodRmReport{(*types.PodRmReport)(0xc0004a26c0)}, VolumeRmReport:[]*types.VolumeRmReport(nil), SecretRmReport:[]*types.SecretRmReport{}}, Secrets:[]types.PlaySecret(nil), ServiceContainerID:"", ExitCode:(*int32)(nil)}, data "{\"Pods\":null,\"Volumes\":null,\"StopReport\":[{\"Errs\":[\"stopping container 0e9607b83672ba5b4304dc457b0069dcd3ff67ba15b73e8d12fe5528babd0e3c: removing container 0e9607b83672ba5b4304dc457b0069dcd3ff67ba15b73e8d12fe5528babd0e3c network: netavark: remove aardvark entries: failed to get aardvark pid: IO error: No such file or directory (os error 2)\"],\"Id\":\"7030de327d895c7c609704240906f9c45c2e1546531a56723743bc4099ce6056\",\"RawInput\":\"liveness-exec-t427-vsmxicvo-unhealthy\"}],\"RmReport\":[{\"RemovedCtrs\":{\"0e9607b83672ba5b4304dc457b0069dcd3ff67ba15b73e8d12fe5528babd0e3c\":null,\"d08ae88d8dd307e8fa2aec881e0d07a49d4725e88bc5cec65f8fb79c2592eeba\":null},\"Err\":null,\"Id\":\"7030de327d895c7c609704240906f9c45c2e1546531a56723743bc4099ce6056\"}],\"VolumeRmReport\":null,\"SecretRmReport\":[],\"Secrets\":null,\"ServiceContainerID\":\"\",\"ExitCode\":null}\n": json: cannot unmarshal string into Go struct field PodStopReport.StopReport.Errs of type error

Seen in f41 root remote. Three instances of the same failure within the same test run (Cirrus task), one right after the other.

[Luap99]

I think this is another one of these dns race conditions as the signal design is just not race free... containers/aardvark-dns#338

I guess for this error on teardown ignoring ENOENT may be fine.

[github-actions]

A friendly reminder that this issue had no activity for 30 days.