Weird Filebeat init script issue

The following fixed it for me - change line 61 in /etc/init.d/filebeat

from:
--exec $WRAPPER -- $WRAPPER_ARGS -- $DAEMON $DAEMON_ARGS \
to:
--exec $WRAPPER -- $WRAPPER_ARGS -- $DAEMON -- $DAEMON_ARGS \

I resorted to this:

'su -m -c "service {{beat}} restart"':
  cmd.run:
    - use_vt: true

I bet it has to do with a env variable... perhaps TERM

I tried the solution but it didn't worked for me...

@DanG what is the filebeat version that you are using? I don't have the same thing on line 61..

In addition the startup command that I have is

daemon $daemonopts $wrapper $wrapperopts -- $agent $args

I too am having this issue with Salt on Ubuntu 14.04. I have discovered a workaround. On line 61 of the init script, replace:

--exec $WRAPPER -- $WRAPPER_ARGS -- $DAEMON $DAEMON_ARGS \

with:

-b --exec $WRAPPER -- $WRAPPER_ARGS -- $DAEMON $DAEMON_ARGS \

filebeat 1.0.1 from the ubuntu/debian package which is where I think you are seeing a differenc.e

You might want to upgrade to filebeat 1.1.1. The 1.1.1 release fixes a critical bug for logstash output possibly hanging.

This seems to work for me. Thanks!

I found a wrong argument in start-stop-daemon args that causes the init script to hang in some chases (like starting through salt or over remote ssh).
The start-stop-daemon argument "-n" requires an input but it is missing.

the following line must be changed in /etc/init.d/filebeat to fix the problem:

  • WRAPPER_ARGS="-r / -n -p $PIDFILE"
  • WRAPPER_ARGS="-r / -p $PIDFILE"

has anyone raised this as an issue to be fixed?

The WRAPPER_ARGS are passed to the *beat-god program, not to start-stop-daemon. The -n for go-daemon means nohup.

This is the go-daemon that I'm talking about: https://github.com/fiorix/go-daemon

And this ticket seems related to the issue here: https://github.com/fiorix/go-daemon/issues/5 Unfortunately no hints about what could cause it.

I'll check if I can find a solution, because on CentOS systems we need go-daemon. But on debian, where we have start-stop-daemon, go-daemon does the same thing so we could get rid of it.

Have you modified the config file of filebeat which is located at /etc/filebeat/filebeat.yml default?
If you have modified the filebeat.yml to make the output to stdout or make stdin tobe the input,problem happens of course for systemd is a deamon process.

This is still an issue. Running the newest Amazon Linux, it is impossible to start filebeat remotely. Does anyone have an idea of how to deal with this? It's a bit disturbing that the last comment was months ago...

I'm happy to experiment further with this, but have no idea where to go next.

@flow_state which version of filebeat are you using?

Is there a fix on this for CentOS6 and filebeat-1.2.3 ?

I think it has been fixed by forking go-deamon and correctly closing file-descriptors when demonizing. See filebeat 1.2.2 release notes

Thanks for responses. Worked perfectly.