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.
Thanks in advance!
Any solution?
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.
Okay thanks I will do that.
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
Yes the pid file have the 644 permisions and the 15511 number. And the
/var/run/suricata
directory doesn’t exist.
I am now at the point where @bloater99 was.
Do a fresh install and check if suricata stays running and if it does, then do a restore from a backup and see if it then also stays running.
Okey thanks I will do that.
The other possibility is update your a few cores behind.
/var/log/messages should have why Suricata is unhappy.
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.
For reference, I have three IPFires. They all have 8GB RAM and IPS enabled with lots of rules. IPS seems to use about 1.2GB on these three systems.
On my system I have just two ruleset providers
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.
I have 1GB of RAM and I was using 3 ruleset providers.
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…