'\" t

.\"     Title: rabbitmqctl

.\"    Author: The RabbitMQ Team <[email protected]>

.\" Generator: DocBook XSL Stylesheets v1.75.2 <http://docbook.sf.net/>

.\"      Date: 05/10/2013

.\"    Manual: RabbitMQ Service

.\"    Source: RabbitMQ Server

.\"  Language: English

.\"

.TH "RABBITMQCTL" "1" "05/10/2013" "RabbitMQ Server" "RabbitMQ Service"

.\" -----------------------------------------------------------------

.\" * set default formatting

.\" -----------------------------------------------------------------

.\" disable hyphenation

.nh

.\" disable justification (adjust text to left margin only)

.ad l

.\" -----------------------------------------------------------------

.\" * MAIN CONTENT STARTS HERE *

.\" -----------------------------------------------------------------

.SH "NAME"

rabbitmqctl \- command line tool for managing a RabbitMQ broker

.SH "SYNOPSIS"

.HP \w'\fBrabbitmqctl\fR\ 'u

\fBrabbitmqctl\fR [\-n\ \fInode\fR] [\-q] {\fIcommand\fR} [\fIcommand\ options\fR...]

.SH "DESCRIPTION"

.PP

RabbitMQ is an implementation of AMQP, the emerging standard for high performance enterprise messaging\&. The RabbitMQ server is a robust and scalable implementation of an AMQP broker\&.

.PP

\fBrabbitmqctl\fR

is a command line tool for managing a RabbitMQ broker\&. It performs all actions by connecting to one of the broker\'s nodes\&.

.PP

Diagnostic information is displayed if the broker was not running, could not be reached, or rejected the connection due to mismatching Erlang cookies\&.

.SH "OPTIONS"

.PP

[\-n \fInode\fR]

.RS 4

Default node is "rabbit@server", where server is the local host\&. On a host named "server\&.example\&.com", the node name of the RabbitMQ Erlang node will usually be rabbit@server (unless RABBITMQ_NODENAME has been set to some non\-default value at broker startup time)\&. The output of

\fBhostname \-s\fR

is usually the correct suffix to use after the "@" sign\&. See rabbitmq\-server(1) for details of configuring the RabbitMQ broker\&.

.RE

.PP

[\-q]

.RS 4

Quiet output mode is selected with the "\-q" flag\&. Informational messages are suppressed when quiet mode is in effect\&.

.RE

.SH "COMMANDS"

.SS "Application and Cluster Management"

.PP

\fBstop\fR [\fIpid_file\fR]

.RS 4

Stops the Erlang node on which RabbitMQ is running\&. To restart the node follow the instructions for

Running the Server

in the

\fBinstallation guide\fR\&\s-2\u[1]\d\s+2\&.

.sp

If a

\fBpid_file\fR

is specified, also waits for the process specified there to terminate\&. See the description of the

\fBwait\fR

command below for details on this file\&.

.RE

.PP

\fBstop_app\fR

.RS 4

Stops the RabbitMQ application, leaving the Erlang node running\&.

.sp

This command is typically run prior to performing other management actions that require the RabbitMQ application to be stopped, e\&.g\&.

\fBreset\fR\&.

.RE

.PP

\fBstart_app\fR

.RS 4

Starts the RabbitMQ application\&.

.sp

This command is typically run after performing other management actions that required the RabbitMQ application to be stopped, e\&.g\&.

\fBreset\fR\&.

.RE

.PP

\fBwait\fR {\fIpid_file\fR}

.RS 4

Wait for the RabbitMQ application to start\&.

.sp

This command will wait for the RabbitMQ application to start at the node\&. It will wait for the pid file to be created, then for a process with a pid specified in the pid file to start, and then for the RabbitMQ application to start in that process\&. It will fail if the process terminates without starting the RabbitMQ application\&.

.sp

A suitable pid file is created by the

\fBrabbitmq\-server\fR

script\&. By default this is located in the Mnesia directory\&. Modify the

\fBRABBITMQ_PID_FILE\fR

environment variable to change the location\&.

.RE

.PP

\fBreset\fR

.RS 4

Return a RabbitMQ node to its virgin state\&.

.sp

Removes the node from any cluster it belongs to, removes all data from the management database, such as configured users and vhosts, and deletes all persistent messages\&.

.sp

For

\fBreset\fR

and

\fBforce_reset\fR

to succeed the RabbitMQ application must have been stopped, e\&.g\&. with

\fBstop_app\fR\&.

.RE

.PP

\fBforce_reset\fR

.RS 4

Forcefully return a RabbitMQ node to its virgin state\&.

.sp

The

\fBforce_reset\fR

command differs from

\fBreset\fR

in that it resets the node unconditionally, regardless of the current management database state and cluster configuration\&. It should only be used as a last resort if the database or cluster configuration has been corrupted\&.

.sp

For

\fBreset\fR

and

\fBforce_reset\fR

to succeed the RabbitMQ application must have been stopped, e\&.g\&. with

\fBstop_app\fR\&.

.RE

.PP

\fBrotate_logs\fR {\fIsuffix\fR}

.RS 4

Instruct the RabbitMQ node to rotate the log files\&.

.sp

The RabbitMQ broker appends the contents of its log files to files with names composed of the original name and the suffix, and then resumes logging to freshly created files at the original location\&. I\&.e\&. effectively the current log contents are moved to the end of the suffixed files\&.

.sp

When the target files do not exist they are created\&. When no

\fBsuffix\fR

is specified, the empty log files are simply created at the original location; no rotation takes place\&.

.RE

.SS "Cluster management"

.PP

\fBjoin_cluster\fR {\fIclusternode\fR} [\-\-ram]

.RS 4

.PP

clusternode

.RS 4

Node to cluster with\&.

.RE

.PP

[\-\-ram]

.RS 4

If provided, the node will join the cluster as a RAM node\&.

.RE

.sp

Instruct the node to become a member of the cluster that the specified node is in\&. Before clustering, the node is reset, so be careful when using this command\&. For this command to succeed the RabbitMQ application must have been stopped, e\&.g\&. with

\fBstop_app\fR\&.

.sp

Cluster nodes can be of two types: disc or RAM\&. Disc nodes replicate data in RAM and on disc, thus providing redundancy in the event of node failure and recovery from global events such as power failure across all nodes\&. RAM nodes replicate data in RAM only (with the exception of queue contents, which can reside on disc if the queue is persistent or too big to fit in memory) and are mainly used for scalability\&. RAM nodes are more performant only when managing resources (e\&.g\&. adding/removing queues, exchanges, or bindings)\&. A cluster must always have at least one disc node, and usually should have more than one\&.

.sp

The node will be a disc node by default\&. If you wish to create a RAM node, provide the

\fB\-\-ram\fR

flag\&.

.sp

After executing the

\fBcluster\fR

command, whenever the RabbitMQ application is started on the current node it will attempt to connect to the nodes that were in the cluster when the node went down\&.

.sp

To leave a cluster,

\fBreset\fR

the node\&. You can also remove nodes remotely with the

\fBforget_cluster_node\fR

command\&.

.sp

For more details see the

\fBclustering guide\fR\&\s-2\u[2]\d\s+2\&.

.RE

.PP

\fBcluster_status\fR

.RS 4

Displays all the nodes in the cluster grouped by node type, together with the currently running nodes\&.

.RE

.PP

\fBchange_cluster_node_type\fR {disc | ram}

.RS 4

Changes the type of the cluster node\&. The node must be stopped for this operation to succeed, and when turning a node into a RAM node the node must not be the only disc node in the cluster\&.

.RE

.PP

\fBforget_cluster_node\fR [\-\-offline]

.RS 4

.PP

[\-\-offline]

.RS 4

Enables node removal from an offline node\&. This is only useful in the situation where all the nodes are offline and the last node to go down cannot be brought online, thus preventing the whole cluster from starting\&. It should not be used in any other circumstances since it can lead to inconsistencies\&.

.RE

.sp

Removes a cluster node remotely\&. The node that is being removed must be offline, while the node we are removing from must be online, except when using the

\fB\-\-offline\fR

flag\&.

.RE

.PP

\fBupdate_cluster_nodes\fR {clusternode}

.RS 4

.PP

clusternode

.RS 4

The node to consult for up to date information\&.

.RE

.sp

Instructs an already clustered node to contact

\fBclusternode\fR

to cluster when waking up\&. This is different from

\fBjoin_cluster\fR

since it does not join any cluster \- it checks that the node is already in a cluster with

\fBclusternode\fR\&.

.sp

The need for this command is motivated by the fact that clusters can change while a node is offline\&. Consider the situation in which node A and B are clustered\&. A goes down, C clusters with B, and then B leaves the cluster\&. When A wakes up, it\'ll try to contact B, but this will fail since B is not in the cluster anymore\&.

\fBupdate_cluster_nodes \-n A C\fR

will solve this situation\&.

.RE

.PP

\fBsync_queue\fR {queue}

.RS 4

.PP

queue

.RS 4

The name of the queue to synchronise\&.

.RE

.sp

Instructs a mirrored queue with unsynchronised slaves to synchronise itself\&. The queue will block while synchronisation takes place (all publishers to and consumers from the queue will block)\&. The queue must be mirrored for this command to succeed\&.

.sp

Note that unsynchronised queues from which messages are being drained will become synchronised eventually\&. This command is primarily useful for queues which are not being drained\&.

.RE

.PP

\fBcancel_sync_queue\fR {queue}

.RS 4

.PP

queue

.RS 4

The name of the queue to cancel synchronisation for\&.

.RE

.sp

Instructs a synchronising mirrored queue to stop synchronising itself\&.

.RE

.SS "User management"

.PP

Note that

\fBrabbitmqctl\fR

manages the RabbitMQ internal user database\&. Users from any alternative authentication backend will not be visible to

\fBrabbitmqctl\fR\&.

.PP

\fBadd_user\fR {\fIusername\fR} {\fIpassword\fR}

.RS 4

.PP

username

.RS 4

The name of the user to create\&.

.RE

.PP

password

.RS 4

The password the created user will use to log in to the broker\&.

.RE

.RE

.PP

\fBdelete_user\fR {\fIusername\fR}

.RS 4

.PP

username

.RS 4

The name of the user to delete\&.

.RE

.RE

.PP

\fBchange_password\fR {\fIusername\fR} {\fInewpassword\fR}

.RS 4

.PP

username

.RS 4

The name of the user whose password is to be changed\&.

.RE

.PP

newpassword

.RS 4

The new password for the user\&.

.RE

.RE

.PP

\fBclear_password\fR {\fIusername\fR}

.RS 4

.PP

username

.RS 4

The name of the user whose password is to be cleared\&.

.RE

.RE

.PP

\fBset_user_tags\fR {\fIusername\fR} {\fItag\fR \&.\&.\&.}

.RS 4

.PP

username

.RS 4

The name of the user whose tags are to be set\&.

.RE

.PP

tag

.RS 4

Zero, one or more tags to set\&. Any existing tags will be removed\&.

.RE

.RE

.PP

\fBlist_users\fR

.RS 4

Lists users\&. Each result row will contain the user name followed by a list of the tags set for that user\&.

.RE

.SS "Access control"

.PP

Note that

\fBrabbitmqctl\fR

manages the RabbitMQ internal user database\&. Permissions for users from any alternative authorisation backend will not be visible to

\fBrabbitmqctl\fR\&.

.PP

\fBadd_vhost\fR {\fIvhostpath\fR}

.RS 4

.PP

vhostpath

.RS 4

The name of the virtual host entry to create\&.

.RE

.sp

Creates a virtual host\&.

.RE

.PP

\fBdelete_vhost\fR {\fIvhostpath\fR}

.RS 4

.PP

vhostpath

.RS 4

The name of the virtual host entry to delete\&.

.RE

.sp

Deletes a virtual host\&.

.sp

Deleting a virtual host deletes all its exchanges, queues, bindings, user permissions, parameters and policies\&.

.RE

.PP

\fBlist_vhosts\fR [\fIvhostinfoitem\fR \&.\&.\&.]

.RS 4

Lists virtual hosts\&.

.sp

The

\fBvhostinfoitem\fR

parameter is used to indicate which virtual host information items to include in the results\&. The column order in the results will match the order of the parameters\&.

\fBvhostinfoitem\fR

can take any value from the list that follows:

.PP

name

.RS 4

The name of the virtual host with non\-ASCII characters escaped as in C\&.

.RE

.PP

tracing

.RS 4

Whether tracing is enabled for this virtual host\&.

.RE

.sp

If no

\fBvhostinfoitem\fRs are specified then the vhost name is displayed\&.

.RE

.PP

\fBset_permissions\fR [\-p \fIvhostpath\fR] {\fIuser\fR} {\fIconf\fR} {\fIwrite\fR} {\fIread\fR}

.RS 4

.PP

vhostpath

.RS 4

The name of the virtual host to which to grant the user access, defaulting to

\fB/\fR\&.

.RE

.PP

user

.RS 4

The name of the user to grant access to the specified virtual host\&.

.RE

.PP

conf

.RS 4

A regular expression matching resource names for which the user is granted configure permissions\&.

.RE

.PP

write

.RS 4

A regular expression matching resource names for which the user is granted write permissions\&.

.RE

.PP

read

.RS 4

A regular expression matching resource names for which the user is granted read permissions\&.

.RE

.sp

Sets user permissions\&.

.RE

.PP

\fBclear_permissions\fR [\-p \fIvhostpath\fR] {\fIusername\fR}

.RS 4

.PP

vhostpath

.RS 4

The name of the virtual host to which to deny the user access, defaulting to

\fB/\fR\&.

.RE

.PP

username

.RS 4

The name of the user to deny access to the specified virtual host\&.

.RE

.sp

Sets user permissions\&.

.RE

.PP

\fBlist_permissions\fR [\-p \fIvhostpath\fR]

.RS 4

.PP

vhostpath

.RS 4

The name of the virtual host for which to list the users that have been granted access to it, and their permissions\&. Defaults to

\fB/\fR\&.

.RE

.sp

Lists permissions in a virtual host\&.

.RE

.PP

\fBlist_user_permissions\fR {\fIusername\fR}

.RS 4

.PP

username

.RS 4

The name of the user for which to list the permissions\&.

.RE

.sp

Lists user permissions\&.

.RE

.SS "Parameter Management"

.PP

Certain features of RabbitMQ (such as the federation plugin) are controlled by dynamic, cluster\-wide

\fIparameters\fR\&. Each parameter consists of a component name, a name and a value, and is associated with a virtual host\&. The component name and name are strings, and the value is an Erlang term\&. Parameters can be set, cleared and listed\&. In general you should refer to the documentation for the feature in question to see how to set parameters\&.

.PP

\fBset_parameter\fR [\-p \fIvhostpath\fR] {\fIcomponent_name\fR} {\fIname\fR} {\fIvalue\fR}

.RS 4

Sets a parameter\&.

.PP

component_name

.RS 4

The name of the component for which the parameter is being set\&.

.RE

.PP

name

.RS 4

The name of the parameter being set\&.

.RE

.PP

value

.RS 4

The value for the parameter, as a JSON term\&. In most shells you are very likely to need to quote this\&.

.RE

.RE

.PP

\fBclear_parameter\fR [\-p \fIvhostpath\fR] {\fIcomponent_name\fR} {\fIkey\fR}

.RS 4

Clears a parameter\&.

.PP

component_name

.RS 4

The name of the component for which the parameter is being cleared\&.

.RE

.PP

name

.RS 4

The name of the parameter being cleared\&.

.RE

.RE

.PP

\fBlist_parameters\fR [\-p \fIvhostpath\fR]

.RS 4

Lists all parameters for a virtual host\&.

.RE

.SS "Policy Management"

.PP

Policies are used to control and modify the behaviour of queues and exchanges on a cluster\-wide basis\&. Policies apply within a given vhost, and consist of a name, pattern, definition and an optional priority\&. Policies can be set, cleared and listed\&.

.PP

\fBset_policy\fR [\-p \fIvhostpath\fR] {\fIname\fR} {\fIpattern\fR} {\fIdefinition\fR} [\fIpriority\fR]

.RS 4

Sets a policy\&.

.PP

name

.RS 4

The name of the policy\&.

.RE

.PP

pattern

.RS 4

The regular expression, which when matches on a given resources causes the policy to apply\&.

.RE

.PP

definition

.RS 4

The definition of the policy, as a JSON term\&. In most shells you are very likely to need to quote this\&.

.RE

.PP

priority

.RS 4

The priority of the policy as an integer, defaulting to 0\&. Higher numbers indicate greater precedence\&.

.RE

.RE

.PP

\fBclear_policy\fR [\-p \fIvhostpath\fR] {\fIname\fR}

.RS 4

Clears a policy\&.

.PP

name

.RS 4

The name of the policy being cleared\&.

.RE

.RE

.PP

\fBlist_policies\fR [\-p \fIvhostpath\fR]

.RS 4

Lists all policies for a virtual host\&.

.RE

.SS "Server Status"

.PP

The server status queries interrogate the server and return a list of results with tab\-delimited columns\&. Some queries (\fBlist_queues\fR,

\fBlist_exchanges\fR,

\fBlist_bindings\fR, and

\fBlist_consumers\fR) accept an optional