Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

conntrack process executed twice #2494

Closed
alban opened this issue May 3, 2017 · 2 comments
Closed

conntrack process executed twice #2494

alban opened this issue May 3, 2017 · 2 comments
Labels
bug Broken end user or developer functionality; not working as the developers intended it

Comments

@alban
Copy link
Contributor

alban commented May 3, 2017

On current master, when running scope without eBPF enabled, I notice two conntrack processes executed with the same parameters:

conntrack --buffer-size 212992 -E -o id -p tcp --any-nat

Both conntrack processes are long-running processes.

I added debug messages in Scope and I see that newConntrackFlowWalker / conntrackWalker is executed twice via:

  1. probe/endpoint/reporter.go:NewReporter
  2. probe/endpoint/connection_tracker.go:newProcfsConnectionTracker

/cc @2opremio @bboreham
other conntrack issues: #2488 ("Faster conntrack parser"), #2118 ("probe: conntrack: fix output parsing")

@2opremio 2opremio added the bug Broken end user or developer functionality; not working as the developers intended it label May 3, 2017
@2opremio 2opremio added this to the Next milestone May 3, 2017
@2opremio
Copy link
Contributor

2opremio commented May 16, 2017

We have always created two long running conntrack processes.

  1. To obtain NAT information on connections
  2. To obtain short-lived connections when ebpf isn't enabled.

The command invocations used to be different (--any-nat was only provided for (1)) before #2135. Specifically, the --any-nat argument was added here as opposed to how conntrack was originally invoked.

This is a problem. It means that, when eBPF is not enabled, which is the default, we are only showing short-lived connections that are NATed.

This has been happening since 1.3.0 (March 27) and it has prevented Scope from showing short-lived connections between containers living in the same host (which are not NATed).

I am frankly really surprised that nobody reported this explicitly before. Even worse, we didn't have a test for it :(

@2opremio
Copy link
Contributor

2opremio commented May 16, 2017

As predicted, I can easily reproduce by running these two containers in the same host:

  1. docker run --name nginx nginx
  2. docker run --name curl tutum/curl bash -c "while true; do curl $(docker inspect -f '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' nginx); sleep 2; done"

Before #2527
screen shot 2017-05-17 at 01 06 36

After #2527

screen shot 2017-05-17 at 01 08 30

@rade rade modified the milestone: Next Jul 28, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Broken end user or developer functionality; not working as the developers intended it
Projects
None yet
Development

No branches or pull requests

3 participants