6.0.1.
I recently upgraded of my sensors to 6.x and at first used an old config file from version 5 and that appeared to work just fine. Yesterday I went through the distribution suricata.yaml for 6.0.1 and tweaked all our local settings and after fixing a few typos suricata started up and ran. Then I realised it was not writing eve.json or stats.log ???
I spent a lot of time comparing the two configs but failed to find anything I thought was significant. The main change was the addition section in eve output dealing with anomalies which I disabled.
One change I noted was to to the logging directory (I normally don’t use /var/log
) and I left it as I dismissed that as inconsequential. Although the suricata.log file was written there there was no eve.json. BIg mistake. This morning it occurred to me that since I don’t run suricata as root the process does not have write access to /var/log
. I switched the logging dir back to /data/sensors
and eve.json
appeared again!
So, what was happening. My guess is that suricata starts up and opens suricata.log which works fine, then at some point it switches user sensors
and at some later point it tries to open eve.json but fails because the process no longer has write permissions in /var/log/suricata
. The real problem is that it does not throw an error???
I have similar problem with the pid file which gets created while suri is running as root
but when suri shuts down it can not remove the it resulting in a restart failing with stale pid file message.
I fixed that by moving the pid file to a directory where the sensor
user has write access so it can remove the file even though it is owned by root
. T
I believe that not giving an error (or even aborting) when it could not open the output file is a bug. Where should I flag that these days?