search

openfrontier / docker-gerrit

Build a Docker image with the Gerrit code review system
Apache License 2.0
197 stars 116 forks source link

Wait for database connection & use init system #69

Closed ju-la-berger closed 7 years ago

ju-la-berger commented 7 years ago

We wait for the database to be ready before starting Gerrit. This is a workaround for Issue 1305.

To properly handle sub-processes and shutdown, we use "dumb-init" as a process supervisor.

The Compose YAMLs in this commit can be used for testing this behavior.

thinkernel commented 7 years ago

Hi there, By using nc to test the port of DB before startup the Gerrit is a brilliant idea. However, dumb-init as the init system looks kind of unnecessary in this case. I understand there are some arguments about how docker containers may handle signals poorly. I tested this Gerrit container by using docker stop/kill commands. It looks that the Gerrit java process, which run as pid 1 currently, can handle these signals very well. I even built and tried a version with dumb-init installed and ran as the process 1. The behavior looks no differences to me. So would you please, submit a PR with only the waiting db scripts?

ju-la-berger commented 7 years ago

Hi there and thanks for your reply!

Regarding the init system: You are right. Due to your use of exec, the Java process becomes PID 1 and everything is fine from this point of view.

But I still have one doubt: Does Gerrit spawn new processes (i.e. besides the JVM, e.g. some Git process)? In that case, the init-system would be useful after all to reap those processes (as the JVM is not a process supervisor).

Let's first clarify this potential issue please. Then I will create a better PR.

thinkernel commented 7 years ago

Hi @ju-la-berger I can't 100% assure that but I think in the JAVA world people usually use multi-threads instead of multi-processes since fork a new JVM might be quit a resource consuming stuff which also isn't a good practice.

However this docker image has an extend feature that you can put some scripts with .nohup as the postfix under the /docker-entrypoint-init.d directory. These scripts will be executed by nohup before starting the daemon. I observed that these processes became zombie/defunct processes after they exit themselves.

The interesting thing is they still become zombie processes even I have dumb-init as the init. That's why I said I found no different behaviors with or without dumb-init. BTW, those processes can be collected after docker stop/kill command. My guess is the upper docker process do the collecting works but I can't confirm that.

My hosts' OS are debian and coreos. You can recreate this issue if you have interests to pursue the root cause of this issue.