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 \
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:
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
© 2020. All Rights Reserved - Elasticsearch
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant logo are trademarks of the Apache Software Foundation in the United States and/or other countries.