Change:
<!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: pull-kubernetes-e2e-kops-aws Which test(s) are failing: [sig-network] Network should set TCP CLOSEWAIT timeout Test (that's what the name appears as, I don't have any more info) Since when has it been failing: 11-28-2018 Testgrid link: Reason for failure: [sig-network] Network should set TCP CLOSEWAIT timeout Test Anything else we need to know: Filing this as a flake as subsequent test executions succeeded. <!-- DO NOT EDIT BELOW THIS LINE --/kind failing-test /kind flake
/sig network
Checking at the logs we can see that the entry disappeared from the conntrack table It couldn' timeout because there is only a 1-second gap between both reads, most probably something closed the connection, but it's hard to know from the log files :thinking:
If this issue has been triaged, please comment . Meta: /athenabot mark-triage-reminder I am a bot run by ‍
If this issue has been triaged, please comment . If you aren't able to handle this issue, consider unassigning yourself and/or adding the label. I am a bot run by vllry. ‍
If this issue has been triaged, please comment . If you aren't able to handle this issue, consider unassigning yourself and/or adding the label. I am a bot run by vllry. ‍
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten
Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . Send feedback to sig-testing, kubernetes/test-infra and/or . /close
Closing this issue. <detailsIn response to : Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . /close Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
seen in
/reopen /assign Looking at one job seems that the pod that is acting as a server is restarted continuously, I need to check if it happens in more jobs, that can be a possible explanation of the flakiness, but is too soon to take conclusions
Reopened this issue. <detailsIn response to : /reopen /assign </details
/open
/reopen it seems it failed yesterday :rolleyes:
Reopened this issue. <detailsIn response to : /reopen Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
just hit it now seems it too fast checking for the pod to be running
/reopen Until this is clean :)
Reopened this issue. <detailsIn response to : /reopen Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
seems there is progress, there was no failure during more than one day in the jobs , however, the jobs there are still registering failures. Is it possible that the are running with older versions?
They all pull from Just to use the latest failure listed on triage as an example: v1.19.0-alpha.2.8+ Looking at the commits in (eg: ) I see that it landed before v1.19.0-alpha.2, so your fix is in there
ok, let it run a few days more and see how it evolves ...
I'm going to close this because there are no errors on the jobs in the last 5 days, and only one error in the that I can't explain, because theoretically, the loop to find the close_wait connection has to run every second during 30 seconds and, in that failure, it only runs 3 times. There are other errors of this test with the output , but those jobs have a considerable amount of test failed (100), so I'm concerned if that can be something environmental causing these failures. /close feel free to reopen
Closing this issue. <detailsIn response to : I'm going to close this because there are no errors on the jobs in the last 5 days, and only one error in the that I can't explain, because theoretically, the loop to find the close_wait connection has to run every second during 30 seconds and, in that failure, it only runs 3 times. Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details

Discussion:
serverNodeInfo.nodeIP, kubeProxyE2eImage)) fr.PodClient().CreateSync(serverPodSpec) <ins> defer fr.PodClient().DeleteSync(serverPodSpec.Name, metav1.DeleteOptions{}, framework.DefaultPodDeletionTimeout) </ins> // The server should be listening before spawning the client pod <del> <-time.After(time.Duration(2) * time.Second) </del> <ins> if readyErr := e2epod.WaitForPodsReady(fr.ClientSet, fr.Namespace.Name, serverPodSpec.Name, 0); readyErr != nil { framework.Failf("error waiting for server pod %s to be ready: %w", serverPodSpec.Name, readyErr) } </ins> // Connect to the server and leak the connection ginkgo.By(fmt.Sprintf( "Launching a client connection on node %v (node ip: %v, image: %v)",

clientNodeInfo.nodeIP, kubeProxyE2eImage)) fr.PodClient().CreateSync(clientPodSpec) <ins> defer fr.PodClient().DeleteSync(clientPodSpec.Name, metav1.DeleteOptions{}, framework.DefaultPodDeletionTimeout) </ins> ginkgo.By("Checking /proc/net/nf_conntrack for the timeout") // These must be synchronized from the default values set in