Suricata

Can you confirm that this is not related to permissions?
Example - the user "suricata" has no permissions to write in the coredump directory defined in suricata.yaml?

thanks

Peter Manev wrote:

Can you confirm that this is not related to permissions?
Example - the user "suricata" has no permissions to write in the coredump directory defined in suricata.yaml?

How can i set the dir in the .yaml? couldn't find any documentation related to this.
I have the following in /etc/sysctl.conf and loaded it (for testing purpose):

kernel.core_pattern = /var/log/suricata/core_%e_%p_%s_%t

Since the folder is owned by suricata and it can write the logfiles (fast.log etc.) i doubt a permission issue.

# Daemon working directory

Nothing defined, since it's not run in -D mode :)

Config is found here: http://paste.geekosphere.org/ZqatQTf8XLm6dRya (except that for the cap test the user part is changed from root to suricata and group as well)

Not sure if it's directly related but i have the same issue with the pidfile.

suricata -c /etc/suricata/suricata-eth4.conf -q 0 --pidfile /tmp/suricata-eth4.pid

I start suricata as "root" user in the shell (or via script), so i let suricata drop the privileges.

What are the permissions of /tmp ?

drwxrwxrwt   3 root root  27K Nov  6 09:12 tmp

Is that the case only when you use " -q 0 " ?

Also with just "-i ethX" the pidfile is not deleted. In "-D" mode i can't say it for sure, since sending "kill -s TERM" is resulting in "Signal Received. Stopping engine." but doesn't stop suricata, it keeps running.

For testing coredump - can you try:

sudo kill -n ABRT `pidof suricata`

On a separate note.
If there is no traffic coming on to the listening interface Suricata will not exit - as you describe. Can you confirm this is the case - when you stop Suricata there is no traffic on the interface?

thanks

Using ABRT results in suricata being stopped but no coredump file and the pidfile not removed.
I tested it with and without traffic, behaviour didn't change.

If i start suricata without "-D" like this:

/usr/sbin/suricata -c /etc/suricata/suricata-eth4.conf -i eth4 --pidfile /tmp/suricata-test.pid

I can confirm that actually (for 2.1beta2) - when running as a user - I can not get it to get a coredump.

And still an issue with 3.0 as well btw

Possible solution: https://github.com/OISF/suricata/pull/3362

There is some new discussion on this, see the linked PR