I’m experiencing the same issue mentioned in IPS won’t start., where the IPS won’t start. When I manually delete the /var/run/suricata.pid file and I run again the IPS, the IPS appears to start, but only briefly. After a second or so, the process terminates unexpectedly, and the suricata.pid file remains in place.
Has anyone encountered this problem and found a solution? My IPS isn’t functioning properly at the moment.
I don’t have a solution, but if it’s feasible, you can try doing a clean install to see if it starts working again. Take a backup first, of course. But try to do a minimal setup and test before restoring the backup. If it works normally, then stops working after you restore the backup, then you know it’s something in your config. At that point it might be faster to just reconfigure the firewall from scratch.
When i have problems like this with a daemon (not just suricata) i would do the following things.
First, look in the IPS entry in the System Logs to see if there are any messages that give a clue on why it is stopping after trying to start.
Second, if that does not give enough info, i go to the console command line and run the start command to see what info it might give there.
‘’‘’/etc/rc.d/init.d/suricata start’‘’’
If that does not give enough info then my last approach is to edit the initscript to remove the redirect to ‘’‘’/dev/null’‘’’ as that should show all messages from trying to start the daemon.
Usually when i have a daemon not wznting to start properly one of the above approaches gives me enough info to figure out what is wrong.
Thanks! I tried everything you said but I didn’t take any clue. There is nothing in the system logs. To try to see something more I change the line 170 from /usr/bin/suricata -c /etc/suricata/suricata.yaml -D $NFQUEUES >/dev/null 2>/dev/null to /usr/bin/suricata -c /etc/suricata/suricata.yaml -D $NFQUEUES. The weird thing is that the IPS it seems work for approximately 10 seconds. And after that the pid dies.
Okay. When when you ran the status command you got the pid as 15511.
Then a while later you got that suricata was not running but the pid file was still present.
Check if that pid file has 15511 in it. It should have that in but it is always good to check. /var/run/suricata.pid
Also can you check if the directory
/var/run/suricata/
exists and if it does what it contains.
If it does exist then you need to delete it which would normally be done via the stop command based on the initscript.
Maybe the suricata control socket has not been removed and that is preventing it properly starting but need to see if that directory exists.
On my IPFire system with a running suricata that directory does not exist.
Also before you delete the pid file can you check if it has permissions of 644
True, I didn’t check that Thanks! I just noticed from the logs that after some time, when the IPS is enabled, I’m running out of RAM, and the process is killed because of this. The log shows ‘Suricata-Main invoked oom-killer.’ My hardware has low specs, and I think I’ve added too many rules.
How much RAM do you have and how much does Suricata want? I noticed that it has become a bit more hungry recently, but it might as well be the rulesets being larger.
Abuse.ch SSLBL Blacklist Rules
Emergingthreats.net Community Rules
and IPS takes around 500MB
My system has 4GB ram and used memory is sitting at around 22% (~800MB) so IPS is the biggest user of the memory but there is still more than enough available.
How much memory do you have on your IPFire system and how many ruleset providers have you selected and how many of the rules from each ruleset provider have you selected.
The more ruleset providers selected and the more rules selected the more memory that is required to support IPS.
When Suricata starts up, it will read the rulesets and compile them into memory so that it can search through them really fast. That requires a lot of CPU time and a lot of RAM. So you might just be a little bit over…