Conntrack fails if net.netfilter.nf_conntrack_acct = 1

[iaguis]

This adds more information to the conntrack lines ("packets" and "bytes") which breaks the line parser introduced in #2095:

Error parsing dumped flow "tcp      6 9 CLOSE src=127.0.0.1 dst=127.0.0.2 sport=45294 dport=9091 packets=3 bytes=164 src=127.0.0.2 dst=127.0.0.1 sport=9091 dport=45294 packets=2 bytes=112 mark=0 use=1 id=305795136": input does not match format

[rade]

Well spotted! PR?

[alban]

It also fails on Fedora because of SELinux being enabled:

Error parsing dumped flow "tcp 6 116 TIME_WAIT src=192.168.35.122 dst=172.217.18.211 sport=40748 dport=443 src=172.217.18.211 dst=192.168.35.122 sport=443 dport=40748 mark=0 secctx=system_u:object_r:unlabeled_t:s0 use=1 id=3032703296": input does not match format

[rade]

All these just seem to add some stuff to the end. Is our parser really so sensitive to trip over that?

[alban]

After #2095, the parser is 3 different Sscanf():
https://github.com/weaveworks/scope/pull/2095/files#diff-fdef364be5b01b6b4b78a0eaa1d0a241R269

But unfortunately, we need the last field (id=), that's why the Sscanf() is sensitive to additions in the middle of the line.

I could try to parse differently (with strings.Split, etc.) and check if the performance does not regress to how it was before with xml.