search

jasonish / docker-suricata

A Suricata Docker image.
https://hub.docker.com/r/jasonish/suricata/
MIT License
250 stars 76 forks source link

Stale pid file when running on docker-compose #4

Closed ManofWax closed 4 years ago

ManofWax commented 4 years ago

Hello I've got the following error message when running the container with docker-compose:

28/11/2019 -- 15:41:31 - <Error> - [ERRCODE: SC_ERR_INITIALIZATION(45)] - pid file '/var/run/suricata.pid' exists and Suricata appears to be running. Aborting!

I've found a work around by adding on docker-entrypoint.sh the following command:

SURICATA_PID=/var/run/suricata.pid

if [ -e ${SURICATA_PID} ]; then 
    rm -f ${SURICATA_PID}
fi

But it will not work if the user specifies a different .pid file. Is there a better solution?

jasonish commented 4 years ago

The latest version of this container does not create a pid file. Are you running an older version? Or have you modified it to drop a configuration file?

ManofWax commented 4 years ago

Hello, yes you are right I did some tests and in one of those I've set the pid in the configuration file, and forgot to remove it.

I've just re-tested right now disabling that setting and it worked like a charm. Sorry for wasting your time :)

While we are there do you think your container is suitable for production? I left it runnig with --af-packet for a day and it looks rock solid.

jasonish commented 4 years ago

If you really need a pid file, keep in mind that if Suricata drops privileges (as this docker container will do by default provided the container as the required capabilities), Suricata is unable to cleanup the pid file itself as its owned by root. On research of this, it appears to be the correct "unix" thing to do. The systemd unit file we ship is smart enough to deal with, but this container doesn't use systemd.

One issue you might run into when using a pidfile, is that a stop and start of a container will lead to this stale pid file error.

jasonish commented 4 years ago

While we are there do you think your container is suitable for production? I left it runnig with --af-packet for a day and it looks rock solid.

I don't see why its any less suitable than a package provided by a distribution and my default choice of build options satisfies your needs (I may add more build options by default). The images are also rebuilt nightly using Github Actions to make sure they are always based on the most recent base image with all updates, etc.