You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
Recently, I've recognized a few times that Suricata service stopped processing files. After analysing what's going on, I've found that Suricata is not running, and the service seems to have no timeout for the initialization. I'm not sure why Suricata isn't running, I haven't found any tracks in logs, neither from the service nor the Suricata inside the container. Restarting container is enough to repair it.
The behaviour of the service looks a little unhealthy as it's trying to reach Suricata in an infinite loop, throwing RecoverableError what prevents scaler from stepping in and recreating the service.
To Reproduce
Steps to reproduce the behavior:
Unfortunately, I don't know an easy way. I assume killing the Suricata process or modifying the service not to start Suricata at all could reproduce the behaviour.
Expected behavior
I would like the service to have a timeout / limit for Suricata to start, and just give up throwing a normal error. Using RecoverableError for the time of the initialization is perfectly fine, but should be stopped after some time.
Screenshots
If applicable, add screenshots to help explain your problem.
Environment (please complete the following information if pertinent):
Assemblyline Version: 4.5.0.18, Suricata service 4.5.0.5
Additional context
The service container has logs like below. Note the time - between the start and last sample are two hours of throwing just RecoverableError.
The /var/log/suricata/suricata.log is finished at 14:30 with a fail of loading some signatures, what isn't a reason to stop Suricata, and looks the same as when everything works.
The text was updated successfully, but these errors were encountered:
kam193
added
assess
We still haven't decided if this will be worked on or not
bug
Something isn't working
labels
Apr 22, 2024
Describe the bug
Recently, I've recognized a few times that Suricata service stopped processing files. After analysing what's going on, I've found that Suricata is not running, and the service seems to have no timeout for the initialization. I'm not sure why Suricata isn't running, I haven't found any tracks in logs, neither from the service nor the Suricata inside the container. Restarting container is enough to repair it.
The behaviour of the service looks a little unhealthy as it's trying to reach Suricata in an infinite loop, throwing
RecoverableError
what prevents scaler from stepping in and recreating the service.To Reproduce
Steps to reproduce the behavior:
Unfortunately, I don't know an easy way. I assume killing the Suricata process or modifying the service not to start Suricata at all could reproduce the behaviour.
Expected behavior
I would like the service to have a timeout / limit for Suricata to start, and just give up throwing a normal error. Using
RecoverableError
for the time of the initialization is perfectly fine, but should be stopped after some time.Screenshots
If applicable, add screenshots to help explain your problem.
Environment (please complete the following information if pertinent):
Additional context
The service container has logs like below. Note the time - between the start and last sample are two hours of throwing just
RecoverableError
.The
/var/log/suricata/suricata.log
is finished at 14:30 with a fail of loading some signatures, what isn't a reason to stop Suricata, and looks the same as when everything works.The text was updated successfully, but these errors were encountered: