Document all server side command line tools

Signed-off-by: Shawn O. Pearce <sop@google.com>
This commit is contained in:
Shawn O. Pearce
2009-05-28 15:12:40 -07:00
parent 2145b71fda
commit 4016a930c5
11 changed files with 528 additions and 8 deletions

View File

@@ -0,0 +1,85 @@
gerrit flush-caches
===================
NAME
----
gerrit flush-caches - Flush some/all server caches from memory
SYNOPSIS
--------
[verse]
'ssh' -p <port> <host> 'gerrit flush-caches' \
[\--all | \--list | \--cache <NAME> ...]
DESCRIPTION
-----------
Clear an in-memory cache, forcing Gerrit to reconsult the ground
truth when it needs the information again.
Flushing a cache may be necessary if an administrator modifies
database records directly in the database, rather than going through
the Gerrit web interface.
If no options are supplied, defaults to `--all`.
ACCESS
------
Caller must be a member of the privileged 'Administrators' group.
SCRIPTING
---------
This command is intended to be used in scripts.
OPTIONS
-------
\--all::
Flush all supported caches. This is like applying a big
hammer, it will force everything out, potentially more than
was necessary for the change made.
\--list::
Show a list of the caches.
\--cache=<NAME>::
Flush only the cache called <NAME>. May be supplied more
than once to flush multiple caches in a single command
execution.
EXAMPLES
--------
List caches available for flushing:
====
$ ssh -p 29418 review.example.com gerrit flush-caches --list
accounts
diff
groups
openid
projects
sshkeys
====
Flush all caches known to the server, forcing them to recompute:
====
$ ssh -p 29418 review.example.com gerrit flush-caches --all
====
or
====
$ ssh -p 29418 review.example.com gerrit flush-caches
====
Flush only the "sshkeys" cache:
====
$ ssh -p 29418 review.example.com gerrit flush-caches --cache sshkeys
====
SEE ALSO
--------
* link:cmd-show-caches.html[gerrit show-caches]
* link:config-gerrit.html#section_cache[Cache Configuration]
* link:config-gerrit.html#cache_names[Standard Caches]

View File

@@ -0,0 +1,48 @@
Gerrit2 - Command Line Tool
===========================
Executing Commands
------------------
Aside from the standard Git server side actions, Gerrit supports
several other commands over its internal SSH daemon. As Gerrit does
not provide an interactive shell, the commands must be triggered
from an ssh client, for example:
$ ssh -p 29418 review.example.com gerrit ls-projects
For more details on how to determine the correct SSH port number,
see link:user-upload.html#test_ssh[Testing Your SSH Connection].
User Commands
-------------
git upload-pack::
Standard Git server side command for client side `git fetch`.
git receive-pack::
Standard Git server side command for client side `git push`.
+
Also implements the magic associated with uploading commits for
review. See link:user-upload.html#push_create[Creating Changes].
link:cmd-ls-projects.html[gerrit ls-projects]::
List projects visible to the caller.
Adminstrator Commands
---------------------
link:cmd-flush-caches.html[gerrit flush-caches]::
Flush some/all server caches from memory.
link:cmd-show-caches.html[gerrit show-caches]::
Display current cache statistics.
link:cmd-show-connections.html[gerrit show-connections]::
Display active client SSH connections.
link:cmd-show-queue.html[gerrit show-queue]::
Display the background work queues, including replication.
link:cmd-replicate.html[gerrit replicate]::
Manually trigger replication, to recover a node.

View File

@@ -0,0 +1,51 @@
gerrit ls-projects
==================
NAME
----
gerrit ls-projects - List projects visible to caller
SYNOPSIS
--------
[verse]
'ssh' -p <port> <host> 'gerrit ls-projects'
DESCRIPTION
-----------
Displays the list of project names, one per line, that the
calling user account has been granted 'READ' access to.
If the caller is a member of the privileged 'Administrators'
group, all projects are listed.
ACCESS
------
Any user who has configured an SSH key.
SCRIPTING
---------
This command is intended to be used in scripts.
EXAMPLES
--------
List visible projects:
=====
$ ssh -p 29418 review.example.com gerrit ls-projects
tools/gerrit
tools/gwtorm
=====
Clone any project visible to the user:
====
for p in `ssh -p 29418 review.example.com gerrit ls-projects`
do
mkdir -p `dirname "$p"`
git clone --bare "ssh://review.example.com:29418/$p.git" "$p.git"
done
====
SEE ALSO
--------
* link:access-control.html[Access Controls]

View File

@@ -0,0 +1,97 @@
gerrit replicate
================
NAME
----
gerrit replicate - Manually trigger replication, to recover a node
SYNOPSIS
--------
[verse]
'ssh' -p <port> <host> 'gerrit replicate' \
[\--url <PATTERN>] \
\{\--all | <PROJECT> ...}
DESCRIPTION
-----------
Schedules replication of the specified projects to all configured
replication destinations, or only those whose URLs match the pattern
given on the command line.
Normally Gerrit automatically schedules replication whenever it
makes a change to a managed Git repository. However, there are
other reasons why an administrator may wish to trigger replication:
* Destination disappears, then later comes back online.
+
If a destination went offline for a period of time, when it comes
back, it may be missing commits that it should have. Triggering a
replication run for all projects against that URL will update it.
* After repacking locally, and using `rsync` to distribute the new
pack files to the destinations.
+
If the local server is repacked, and then the resulting pack files
are sent to remote peers using `rsync -a \--delete-after`, there
is a chance that the rsync missed a change that was added during
the rsync data transfer, and the rsync will remove that changes's
data from the remote, even though the automatic replication pushed
it there in parallel to the rsync.
+
Its a good idea to run replicate with `\--all` to ensure all
projects are consistent after the rsync is complete.
* After deleting a ref by hand.
+
If a ref must be removed (e.g. to purge a change or patch set
that shouldn't have been created, and that must be eradicated)
that delete must be done by direct git access on the local,
managed repository. Gerrit won't know about the delete, and is
unable to replicate it automatically. Triggering replication on
just the affected project can update the mirrors.
ACCESS
------
Caller must be a member of the privileged 'Administrators' group.
SCRIPTING
---------
This command is intended to be used in scripts.
OPTIONS
-------
\--all::
Schedule replicating for all projects.
\--url=<PATTERN>::
Replicate only to replication destinations whose URL
contains the substring <PATTERN>. This can be useful to
replicate only to a previously down node, which has been
brought back online.
EXAMPLES
--------
Replicate every project, to every configured remote:
====
$ ssh -p 29418 review.example.com gerrit replicate --all
====
Replicate only to `srv2` now that it is back online:
====
$ ssh -p 29418 review.example.com gerrit replicate --url=srv2 --all
====
Replicate only the `tools/gerrit` project, after deleting a ref
locally by hand:
====
$ git --git-dir=/home/git/tools/gerrit.git update-ref -d refs/changes/00/100/1
$ ssh -p 29418 review.example.com gerrit replicate tools/gerrit
====
SEE ALSO
--------
* link:config-replication.html[Git Replication/Mirroring]

View File

@@ -0,0 +1,74 @@
gerrit show-caches
===================
NAME
----
gerrit show-caches - Display current cache statistics
SYNOPSIS
--------
[verse]
'ssh' -p <port> <host> 'gerrit show-caches'
DESCRIPTION
-----------
Display statistics about the size and hit ratio of in-memory caches.
ACCESS
------
Caller must be a member of the privileged 'Administrators' group.
SCRIPTING
---------
Intended for interactive use only.
EXAMPLES
--------
====
$ ssh -p 29418 review.example.com gerrit show-caches
cache "diff" (memory, disk):
items : 16519
items.memory: 153
items.disk : 16384
evictions : 0
ttl.idle : 90.00 days
ttl.live : inf
avg.get : 0.67 ms
hit% : 85%
hit%.memory : 55%
hit%.disk : 30%
cache "openid":
items : 8
evictions : 0
ttl.idle : 5.00 mins
ttl.live : 5.00 mins
avg.get : 1.00 ms
hit% : 5%
cache "sshkeys":
items : 4
evictions : 0
ttl.idle : 90.00 days
ttl.live : inf
avg.get : 0.06 ms
hit% : 92%
JGit Buffer Cache:
open files : 9
loaded : 9.99 mb
mem% : 3%
JVM Heap:
max : 880.00 mb
inuse : 166.96 mb
mem% : 57%
====
SEE ALSO
--------
* link:cmd-flush-caches.html[gerrit flush-caches]
* link:config-gerrit.html#section_cache[Cache Configuration]
* link:config-gerrit.html#cache_names[Standard Caches]

View File

@@ -0,0 +1,84 @@
gerrit show-connections
=======================
NAME
----
gerrit show-connections - Display active client SSH connections
SYNOPSIS
--------
[verse]
'ssh' -p <port> <host> 'gerrit show-connections' [-n]
DESCRIPTION
-----------
Presents a table of the active SSH connections, the users who
are currently connected to the internal server and performing
an activity.
ACCESS
------
Caller must be a member of the privileged 'Administrators' group.
SCRIPTING
---------
Intended for interactive use only.
OPTIONS
-------
-n::
\--numeric::
Show client hostnames as IP addresses instead of DNS hostname.
DISPLAY
-------
Start::
Time (local to the server) that this connection started.
Idle::
Time since the last data transfer on this connection.
Note that most SSH clients use not only a TCP based
connection keep-alive, but also an encrypted keep alive
higher up in the SSH protocol stack. That higher keep
alive resets the idle timer, about once a minute.
User::
The SSH User Name of the account that is authenticated on
this connection. If the -n option is used, this column
shows the Account Id instead.
Remote Host::
Reverse lookup hostname, or if -n option is used, the remote
IP address.
[ second line ]::
Command(s) actively being executed on this connection.
With SSH channel multiplexing a single connection can
perform multiple commands, or a connection can be idle,
performing nothing at all.
EXAMPLES
--------
With reverse DNS lookup (default):
====
$ ssh -p 29418 review.example.com gerrit show-connections
Start Idle User Remote Host
--------------------------------------------------------------
14:02:47 00:00:00 jdoe jdoe-desktop.example.com
[ gerrit-show-connections ]
--
====
Without reverse DNS lookup:
====
$ ssh -p 29418 review.example.com gerrit show-connections -n
Start Idle User Remote Host
--------------------------------------------------------------
14:02:48 00:00:00 a/1001240 10.0.0.1
[ gerrit-show-connections -n ]
--
====

View File

@@ -0,0 +1,75 @@
gerrit show-queue
=================
NAME
----
gerrit show-queue - Display the background work queues, including replication
SYNOPSIS
--------
[verse]
'ssh' -p <port> <host> 'gerrit show-queue'
DESCRIPTION
-----------
Presents a table of the pending background activity the Gerrit
daemon will perform in the near future. Gerrit contains an internal
scheduler, similar to cron, that it uses to queue and dispatch both
short and long term background activity.
Tasks that are completed or cancelled exit the queue very quickly
once they enter this state, but it can be possible to observe tasks
in these states.
ACCESS
------
Caller must be a member of the privileged 'Administrators' group.
SCRIPTING
---------
Intended for interactive use only.
DISPLAY
-------
S::
Current state of the task. States are:
+
* `D`: task is complete, but hasn't released its worker yet.
* `C`: task has been cancelled, but hasn't left the queue yet.
* `R`: task is actively running on a worker thread.
* `W`: task is ready to run, waiting for a worker thread.
* `S`: task is sleeping until its Start time.
Start::
Time (local to the server) that this task will begin
execution. Blank if the task is completed, running, or
ready to run but is waiting for a worker thread to become
available.
Task::
Short text description of the task that will be performed
at the given time.
EXAMPLES
--------
The following queue contains two tasks scheduled to replicate the
`tools/gerrit.git` project to two different remote systems, `dst1`
and `dst2`:
====
$ ssh -p 29418 review.example.com gerrit show-queue
S Start Task
--------------------------------------------------------------
S 14:31:15.435 mirror dst1:/home/git/tools/gerrit.git
S 14:31:25.434 mirror dst2:/var/cache/tools/gerrit.git
--------------------------------------------------------------
2 tasks
====
DEFECTS
-------
There is a small race condition where tasks may disappear from the
output of this command while they transition from the ready/waiting
(`W`) or sleeping (`S`) state to the running (`R`) state.

View File

@@ -93,8 +93,8 @@ unused mapped spaces fast enough.
Default on JGit is false. Although potentially slower, it yields
much more predictable behavior.
Section cache
~~~~~~~~~~~~~
Section cache[[section_cache]]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cache.directory::
+
@@ -148,8 +148,8 @@ Default is 5 MiB.
+
Common unit suffixes of 'k', 'm', or 'g' are supported.
Standard Caches
^^^^^^^^^^^^^^^
Standard Caches[[cache_names]]
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
cache `"diff"`::
+
@@ -181,6 +181,8 @@ is per-user, so 1024 items translates to 1024 unique user accounts.
As each individual user account may configure multiple SSH keys,
the total number of keys may be larger than the item count.
See also link:cmd-flush-caches.html[gerrit flush-caches].
Section sshd
~~~~~~~~~~~~

View File

@@ -47,6 +47,9 @@ different hosts:
threads = 3
====
To manually trigger replication at runtime, see
link:cmd-replicate.html[gerrit replicate].
File `replication.config`[[replication_config]]
-----------------------------------------------

View File

@@ -4,6 +4,7 @@ Gerrit Code Review for Git
User Guide
----------
* link:cmd-index.html[Command Line Tools]
* link:user-upload.html[Uploading Changes]
* link:access-control.html[Access Controls]

View File

@@ -51,8 +51,8 @@ key's passphrase. Consult `man ssh-agent`, or your SSH client's
documentation, for more details on configuration of the agent
process and how to add the private key.
Testing Your SSH Connection
---------------------------
Testing Your SSH Connection[[test_ssh]]
---------------------------------------
To verify your SSH key is working correctly, try using an SSH client
to connect to Gerrit's SSHD port. By default Gerrit is running on
@@ -108,8 +108,8 @@ be sent through command line options.
For more details on using `repo upload`, see `repo help upload`.
git push: Create Changes
------------------------
git push: Create Changes[[push_create]]
---------------------------------------
To create new changes for review, simply push into the project's
magical `refs/for/'branch'` ref using any Git client tool: