e24c71fb86
Our startup script is extracted into $site_path/bin/gerrit.sh so administrators can easily link to it in their /etc/rc.d management. This script is based heavily upon the jetty.sh that comes in any Jetty distribution, so we're opting to relicense it under the Apache License version 2.0, rather than the Eclipse Public License. Most of the script is intact, but I've certainly butchered and reworked some parts that were really Jetty specific. If /usr/bin/perl is available (these days it is on most systems) we use that to launch the JVM rather than the shell. This allows us to force the process name as reported by ps to be 'GerritCodeReview' rather than '/usr/bin/java', which can really help to nail down which JVM is your Gerrit daemon. If perl isn't found we stick the unused system property -DGerritCodeReview=1 as early in the command line as we can, to help ps challenged systems to still identify us. We store the pid file for our running daemon in $site_path/logs, rather than /tmp or /var/tmp, so its easier to locate and match to a specific site path installation. During `gerrit init` we try to capture the relevant parameters to locate the JRE and gerrit.war and stuff them into gerrit.config so the start script can find them later on. Adminstrators can always adjust these later on if necessary. If git isn't available to read the gerrit.config with during startup we use a crude but workable configuration parser written entirely in Bourne shell. It should be just good enough to scan through the gerrit.config and pull out container.javaHome and container.war, which is about all we need to boot ourselves. Change-Id: I52872b1acffc22e80c5fd33fd6df0e152bc96cff Signed-off-by: Shawn O. Pearce <sop@google.com>