EOFError when using tcp output plugin

[jordansissel]

(This issue was originally filed by @Akshaykapoor at elastic/logstash#2999)

---

I have a custom plugin which is inheriting the tcp output plugin. The error that i receive is,

tcp output exception {:host=>"localhost", :port=>3030, :exception=>#<EOFError: End of file reached>, :backtrace=>["org/jruby/RubyIO.java:3003:in `sysread'", "/opt/logstash/lib/logstash/outputs/tcp.rb:105:in `register'", "org/jruby/RubyProc.java:271:in `call'", "/opt/logstash/lib/logstash/codecs/json.rb:45:in `encode'", "/opt/logstash/lib/logstash/outputs/tcp_custom.rb:42:in `receive'", "/opt/logstash/lib/logstash/outputs/base.rb:86:in `handle'", "(eval):924:in `initialize'", "org/jruby/RubyProc.java:271:in `call'", "/opt/logstash/lib/logstash/pipeline.rb:266:in `output'", "/opt/logstash/lib/logstash/pipeline.rb:225:in `outputworker'", "/opt/logstash/lib/logstash/pipeline.rb:152:in `start_outputs'"], :level=>:warn}

This happens for every alternate event when received by sensu. I tried running with tcp output plugin but the results are still the same EOFError.

[Akshaykapoor]

Looking at the code, for output tcp plugin, i see the comment in there for the exception that is expected and i receive the same.

my tcp plugin config is on the default that is set to be the client, one thing i don't quite understand is the reason for this open read_socket. Maybe someone can help me in understanding this.

      @codec.on_event do |payload|
        begin
          client_socket = connect unless client_socket
          r,w,e = IO.select([client_socket], [client_socket], [client_socket], nil)
          # don't expect any reads, but a readable socket might
          # mean the remote end closed, so read it and throw it away.
          # we'll get an EOFError if it happens.
          client_socket.sysread(16384) if r.any?

          # Now send the payload
          client_socket.syswrite(payload) if w.any?
        rescue => e
          @logger.warn("tcp output exception", :host => @host, :port => @port,
                       :exception => e, :backtrace => e.backtrace)
          client_socket.close rescue nil
          client_socket = nil
          sleep @reconnect_interval
          retry

[Vehyla]

I am experiencing the same thing. It usually makes logstash fall over after a bit of time.

[stuart-warren]

/watch

[Akshaykapoor]

@stuart-warren what do you mean by your comment ?

[stuart-warren]

@Akshaykapoor I also have the same problem, so watching the ticket :)
Specifically logstash-output-tcp from one instance to another instance running logstash-input-tcp

[docwhat]

Is there a work-around until this is fixed?

[RMAdeveloper]

any news?

[cssccarvalho]

Hello,

I'm having the same problem of trying to use the logstash 2.3 with default tcp output plugin. My goal is to send json formated messages to sensu.

Can anybody help?

[signus]

I am seeing this issue on 2.3.4 and 5.0.0-alpha4 with logstash-output-tcp 3.2.0.

According to the register function:

# don't expect any reads, but a readable socket might
# mean the remote end closed, so read it and throw it away.
# we'll get an EOFError if it happens.

Where a readable socket without data means that the socket is ready to be closed. This should not be problematic, but if it is causing performance issues for people (probably means that the socket descriptor could be holding onto inodes for Linux/OSX), it needs to be looked into.

[beeleebow]

So no progress on this?

[ldormoy]

I encounter the same issue. tcp output plugin sending data to tcp input plugin.

[xtruthx]

i experienced the same issue. i am using a tcp output at logstash node1 and tcp input at logstash node2.
logstash version is 5.5.1 on node1 and on node2 it is logstash version 5.4.3. On the input node i am not able to use also 5.5.1. Reason is that i use plugin which depends acutally on this version.
Question is there a valid workaround. Sure using udp is may in my case a option but not the best. Both Systems are RHEL7 systems.

[jsmucr]

This goes deeper. I recently discovered a weird behavior with the GELF output plugin. Later I figured out it discards the first message it's supposed to send to a connection that has been closed by the server side. The situation is simple to simulate on Linux:

1. Create a numbered message generator of some kind.
2. Download NetCat.
3. Create a simple bridge-like Logstash configuration (i.e. raw UDP to raw TCP).
4. Run NetCat on localhost (i.e. nc -kl 12201)
5. Open another terminal window and generate some messages. All should be delivered to the first terminal window.
6. Close NetCat (Ctrl+C) and start it again.
7. Generate at least two numbered messages. All but the first one will be delivered.
8. In case of the tcp output plugin, an exception will appear in the log (which is how I finally learned what is wrong and found this thread).

This is IMHO a critical bug that needs to be fixed ASAP.