# \[pgsql\] Flow stop **URL:** \ **Category:** Beats\ **Tags:** packetbeat\ **Created:** [February 1, 2017, 3:12pm UTC](https://discuss.elastic.co/t/pgsql-flow-stop/73536 "2017-02-01T15:12:58Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![kim\_85](https://avatars.discourse-cdn.com/v4/letter/k/f6c823/32.png) [@kim\_85](https://discuss.elastic.co/u/kim_85)\ **Post date:** [February 1, 2017, 3:12pm UTC](https://discuss.elastic.co/t/pgsql-flow-stop/73536/1 "2017-02-01T15:12:58Z")
Hi, I have many installation of packetbeat connected to elasticsearch. Sometimes on a few vm, the packetbeat flow stop with this mistake : > 2017-01-30T06:39:30+01:00 ERR Pgsql invalid column\_length=4294967295, buffer\_length=4, i=3 > 2017-01-30T06:39:30+01:00 ERR Pgsql invalid column\_length=4294967295, buffer\_length=4, i=3 > 2017-01-30T06:39:30+01:00 WARN Pgsql parser expected extended query message, but received command of type 80 > 2017-01-30T06:39:37+01:00 INFO Non-zero metrics in the last 30s: pgsql.unmatched\_responses=348 libbeat.es.publish.read\_bytes=13257 libbeat.es.publish.write\_bytes=481378 libbeat.es.published\_and\_acked\_events=783 libbeat.es.call\_count.PublishEvents=31 libbeat.publisher.published\_events=776 tcp.dropped\_because\_of\_gaps=2 libbeat.publisher.messages\_in\_worker\_queues=261 > 2017-01-30T06:40:07+01:00 INFO No non-zero metrics in the last 30s > 2017-01-30T06:40:37+01:00 INFO No non-zero metrics in the last 30s > 2017-01-30T06:41:07+01:00 INFO No non-zero metrics in the last 30s > 2017-01-30T06:41:37+01:00 INFO No non-zero metrics in the last 30s > 2017-01-30T06:42:07+01:00 INFO No non-zero metrics in the last 30s My config : > packetbeat.interfaces.device: any > packetbeat.flows: > timeout: 30s > packetbeat.protocols.pgsql: > enabled: true > ports: 6432 > output.elasticsearch: > hosts: xxx:9200 > template.enabled: true > template.path: packetbeat.template.json Packetbeat is connecting to pgbouncer Other vm continue to send data normaly. I restart the packetbeat process and the flow return again data Do you have an idea of the problem ? Thanks ---
**Author:** ![steffens](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/steffens/32/79630_2.png) [@steffens](https://discuss.elastic.co/u/steffens)\ **Post date:** [February 1, 2017, 6:38pm UTC](https://discuss.elastic.co/t/pgsql-flow-stop/73536/2 "2017-02-01T18:38:43Z")
looks like packetbeat is seening a message it can not handled. No idea what `command type 80` is, though. It can happen the protocol analyzer not being in sync with the actual network stream. This can happen either on start of packetbeat (if it starts to capture in middle of ongoing transaction), or after some packet loss, e.g. this `tcp.dropped_because_of_gaps=2` indicates packet loss. Have you tried to run packetbeat with `af_packet`? ---
**Author:** ![steffens](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/steffens/32/79630_2.png) [@steffens](https://discuss.elastic.co/u/steffens)\ **Post date:** [February 1, 2017, 6:39pm UTC](https://discuss.elastic.co/t/pgsql-flow-stop/73536/3 "2017-02-01T18:39:52Z")
btw. if parser detects error, it drops the connection and restarts capturing the connection. That is a restart of packetbeat should not be necessary. ---
**Author:** ![kim\_85](https://avatars.discourse-cdn.com/v4/letter/k/f6c823/32.png) [@kim\_85](https://discuss.elastic.co/u/kim_85)\ **Post date:** [February 2, 2017, 3:16pm UTC](https://discuss.elastic.co/t/pgsql-flow-stop/73536/4 "2017-02-02T15:16:33Z")
Thanks for you answer. I am trying to run packetbeat with af\_packet flag. The flow run normaly since this morning. I'll see tomorrow if it's still ok Indeed, i not understand why packetbeat stop flux and can't restart automatically...Is a defaut parametres ? ---
**Author:** ![steffens](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/steffens/32/79630_2.png) [@steffens](https://discuss.elastic.co/u/steffens)\ **Post date:** [February 3, 2017, 4:12pm UTC](https://discuss.elastic.co/t/pgsql-flow-stop/73536/5 "2017-02-03T16:12:56Z")
> [@kim\_85](#): > > Indeed, i not understand why packetbeat stop flux and can't restart automatically...Is a defaut parametres ? Sorry, but I don't fully understand what you're saying. There is no parameter to restart a protocol analyzer. It just drops some state and continues processing. On of the problems with packet-loss is too much state potentialy piling up in memory. This requires more time to clean up state. Plus, whenever state needs to be dropped, we have to resync the TCP stream. For resync the parser has to try to parse the TCP stream in the middle (and potentially throw away state, as not yet in sync), adding more temporary state to be cleaned up. That is packet loss can make problems worse due to additional processing required (it's a vicious cycle packetbeat might not be able to escape from). By restarting packetbeat you drop all state, which might help for some time, until the vicious cycle begins again (all passive deep packet analyzers face similar problems). ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [March 3, 2017, 4:13pm UTC](https://discuss.elastic.co/t/pgsql-flow-stop/73536/6 "2017-03-03T16:13:08Z")
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.