Not binding to ports when running as regular user
Description
testing discovered
Gliffy Diagrams
Activity
bruno miguel May 28, 2014 at 6:51 PM
Hi Jordan,
i am having the same issue in Debian 7.5.
installed logstash 1.4.1-1-bd507eb and elasticsearch 1.1.2 with apt-get, from official repositories
this is my config for input:
input {
udp {
type => "syslog"
port => "514"
}
}
when i start logstash service i get the same error, over and over again:
{:timestamp=>"2014-05-28T19:28:54.566000+0100", :message=>"UDP listener died", :exception=>#<SocketError: bind: name or service not known>, :backtrace=>["org/jruby/ext/socket/RubyUDPSocket.java:160:in `bind'", "/opt/logstash/lib/logstash/inputs/udp.rb:69:in `udp_listener'", "/opt/logstash/lib/logstash/inputs/udp.rb:50:in `run'", "/opt/logstash/lib/logstash/pipeline.rb:163:in `inputworker'", "/opt/logstash/lib/logstash/pipeline.rb:157:in `start_input'"], :level=>:warn}
i dont get that error if i change to 1514 port
i dont get that error if i run logstash as ./opt/logstash/bin/logstash -f /etc/logstash/conf.d/logstash.conf
the init.d script has something like (dont know if its relevant):
if [ `id -u` -ne 0 ]; then
echo "You need root privileges to run this script"
exit 1
fi
anyway i now must always have a open window in ssh for it to run
maybe the start scritp must be rewritten?
Wesley DeCesare April 2, 2014 at 5:31 PMEdited
My $0.02 on this issue. Using setcap on the Java binary on a CentOS / RHEL 6 system causes the error "error while loading shared libraries: libjli.so: cannot open shared object file: No such file or directory." The solution is documented on Oracle's support site: http://bugs.java.com/view_bug.do?bug_id=7157699 (Also, another discussion about the problem can be found here: http://unix.stackexchange.com/questions/87978/how-to-get-oracle-java-7-to-work-with-setcap-cap-net-bind-serviceep )
So, to keep logstash as non-root and simultaneously not tamper with the Java binary and libraries... I tampered with iptables. I made logstash listen on 1514 and then had iptables stand on its head to redirect inbound port 514 (tcp and udp, for the odd occasions where syslog is using tcp) to localhost:1514.
y April 29, 2013 at 10:26 AM
PEBKAC ofc.
Turns out a Java process was holding it, which appears to be from a dead/zombie process of Logstash itself (as seen by `netstat -plunt|grep 514`). This is somewhat weird, because the tcp listener defined in the same config was not active.
Might be an idea to clarify the error message slightly, to ensure dumb users like me that the bind address is in fact in use by another process.
Jordan Sissel April 25, 2013 at 5:37 PM
When I test it:
port 514 in use; logstash as root: SocketError: bind: name or service not known
port 514 available; logstash as root: works
port 514 available; logstash as nonroot; java with cap_net_bind_service; works
Jordan Sissel April 25, 2013 at 5:31 PM
are you certain something isn't already listening on port 514?
Details
Details
Assignee
Logstash DevelopersReporter
y
Using the following config:
tcp {
port => 5000
type => vcs
}
udp {
port => 5000
type => vcs
}
tcp {
port => 514
type => syslog
}
udp {
port => 514
type => syslog
}
Running with the config above using a non-privilegded user doesn't bind ports. Exected output is a warning in log about port 514 not being able to bind, and a successful bind on port 5000.
What's actually logged is:
{:message=>"UDP listener died", :exception=>#<SocketError: bind: name or service not known>, :backtrace=>["org/jruby/ext/socket/RubyUDPSocket.java:160:in `bind'", "file:/usr/share/logstash/logstash.jar!/logstash/inputs/udp.rb:56:in `udp_listener'", "file:/usr/share/logstash/logstash.jar!/logstash/inputs/udp.rb:39:in `run'", "file:/usr/share/logstash/logstash.jar!/logstash/agent.rb:714:in `run_input'", "file:/usr/share/logstash/logstash.jar!/logstash/agent.rb:367:in `start_input'"], :level=>:warn}
without any of the ports bound, as seen by "netstat -napt | grep -i LISTEN"
Running with the above config as user root works fine.
Suggestion: Would it be possible to have logstash bind to port 514 without running with root priviliges? E.G logstash using "setuid" to drop down to user level after bind, but before accepting connections?
Ideally, I'd want to utilize adm group for access to /var/log/syslog, and run on default syslog port without root privileges.