text: PID 1 in Docker persistance
  I have set up a Kippo server to run in a docker container. Everything runs fine,until you kill the container. Killing the container(by restarting the machine or through docker kill) makes it unusable with STDERR “Another twistd server is running, PID 1”. How can I solve this problem? I don’t have issues to reset the file system of the container or something like this because everything I want is logged to a database. Thank you very much
  2 Solutions collect form web for “PID 1 in Docker persistance”
  Within Docker, each container runs in its own PID namespace. This means that the process started by the dockerfile will always be PID 1, and PIDs will count upwards from there.
  twistd expects that PIDs are non-deterministic enough that it can check to see if another
  twistd is “already running” by simply comparing to see if the PID is the same. Since, in Docker, the PID will always be 1, this check always succeeds, and
  twistd thinks it shouldn’t start up. If the container exits un-cleanly,
  twistd won’t get the opportunity to clean up its
  .pid file, and the state will be preserved within the container’s filesystem.
  Since the Docker daemon will namespace containers and prevent two matching
  twistd processes from starting up at the same time anyway, the
  .pid file and its related checking is not actually useful at all, so you should disable it. You can disable it by changing your command line to include the
  --pidfile= option (exactly as such, nothing after the “
  =“) before the plugin name. I’m not familiar with Kippo, but for
  twistd web this would be
  twistd --pidfile= web.
  I hope that this helps!
  It sounds like your pid1 in the container is not properly cleaning up after itself when it is told to stop. This likely means it does not remove its pidfile, so when you go to start the container again it refuses to start.
  One way to handle this may be to introduce something like supervisord that can handle receiving the stop signal, and then gracefully shut down the kippo server.
  Another solution might be to simply start the container in read-only mode. In read-only mode, the container doesn’t get a write layer, and the root filesystem is simply read-only. Kippo may, however, refuse to start if it can’t create a pidfile to begin with. (see
  docker run --read-only)
  Yet another solution would be to set up an ENTRYPOINT script that removes the pidfile before calling exec on kippo.