[Solved] Logstash 5 alpha3 not starting

Elastic Stack Logstash
#1

Hello,

I am trying to configure logstah 5.0.0 apha3 and when I start the logstash init I get the following message:

"Logstash has a new settings file which defines start up time settings. This file is typically located in $LS_HOME/config or /etc/logstash. If you installed Logstash through a package and are starting it manually please specify the location to this settings file by passing in "--path.settings=/path/.." in the command line options {:level=>:warn}
Failed to load settings file from "path.settings". Aborting... {"path.settings"=>"/usr/share/logstash/config", "exception"=>Errno::ENOENT, "message"=>"No such file or directory - /usr/share/logstash/config/logstash.yml", :level=>:fatal}"

I have changed the /etc/default/logstash to point to the correct folders but still not managing to start it up.

I would appreciate any help on this matter.

Regards,
Peter

#2

What system is this?

How are you starting Logstash?

#3

It is a docker built on debian jessie. Since systemd does not work in docker I am forced to fail over to systemv but the init script for systemv are not getting generated.

#4

From what I can tell, this is more of a Docker issue, and it can be worked around:

Do not drop CAP_SYS_ADMIN from the container. A number of fs namespacing related settings, such as PrivateDevices=, ProtectHome=, ProtectSystem=, MountFlags=, PrivateTmp=, ReadWriteDirectories=, ReadOnlyDirectories=, InaccessibleDirectories=, MountFlags= need to be able to open new mount namespaces and the mount certain file system into it. You break all services that make use of these flags if you drop the flag. Note that already quite a number of services make use of this as we actively encourage users to make use of this security functionality. Also note that logind mounts XDG_RUNTIME_DIR as tmpfs for all logged in users and won't work either if you take away the capability. (Also see section about fully unprivileged containers below.)

Re-adding CAP_SYS_ADMIN seems to fix the issue. We may try to allow users to force init styles, but this is not pressing if there's a way to fix the larger issue by fixing the container instead.

#5

Got it fixed. adding --cap-add SYS_ADMIN with the /sbin/init command will make systemctl command work as expected. Thanks for your help

#6