influxdata / influxdata/kapacitor
Influx and Kapacitor leave connections open over IPv6
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 2.4k
- Forks
- 479
- Avg merge
- 4d 16h
- Merged PRs (30d)
- 4
Description
As noted in #2400 , it is possible to configure Kapacitor and Influx to run on bare IPv6 addresses, but I've discovered that if you do so, then the connections between the two do not get closed the way they should, and eventually, Kapacitor fails because it has too many open files.
I tested this on Rhel7 and Ubuntu, using these versions (Ubuntu shown), which I installed after downloading from the official downloads page:
InfluxDB v1.8.2 (git: 1.8 6a1299e8c6c81ef8fd573ed2b700217121baf04e)
Kapacitor OSS 1.5.6 (git: HEAD ee3f609cd1c96f7c8f4eea924278db1fb2a96f0b)
Relevant config from kapacitor.conf file:
```
hostname = "[::1]"
[http]
bind-address = "[::1]:9092"
[[influxdb]]
urls = ["http://[::1]:8086"]
```
And the influx config:
```
[http]
bind-address = "[::1]:8086"
```
After starting them up (even with no tasks configured in Kapacitor) you should be able to see the connections between Kapacitor and Influx piling up, either using netstat or lsof.
I used `lsof -p | wc -l` and ran that several times over the course of a few minutes. I saw the number of open connections increasing, while that number remained steady when I ran these components in a different configuration. It will take a while for this to cause an issue, but it will happen eventually.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reproducing the issue with the Kapacitor and InfluxDB configurations in kapacitor.conf and the InfluxDB HTTP bind-address, using bare IPv6 addresses. Monitor the Kapacitor process with lsof or netstat over several minutes; done means the connections no longer accumulate when no tasks are configured.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go, linux
- Domain
- backend, networking
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 38/100