
This is the RabbitMQ Server Administrator's Guide. (Note: it is still under development. Please contact us if you have any suggestions or wished-for features!)
Please see the build and installation guides for instructions on compiling, installing, starting and shutting down the server. See the service guide for instructions on running the server as a Windows Service.
When the server first starts running, and detects that its database is uninitialised or has been deleted, it initialises a fresh database with the following resources:
/
guest with a default password of
guest, granted full access to the / virtual host. See here for password-changing
instructions.
rabbitmqctl is a command line tool for managing
a RabbitMQ broker. It performs all actions by connecting to
one of the broker's node. By default that is the node named
"rabbit" on the local host. This can be overridden by
explicitly specifying the node name before the command using
the "-n" flag, e.g.
rabbitmqctl -n rabbit@shortstop add_user tonyg changeit
This command instructs the RabbitMQ broker at the Erlang node rabbit@shortstop to create a user named tonyg with (initial) password changeit.
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 hostname -s is usually the
correct suffix to use after the "@" sign.
rabbitmqctl produces verbose output by default.
Quiet mode can be selected by specifying the "-q" flag, e.g.
rabbitmqctl -q status
This option enables quiet mode and is useful when post-processing the results. Informational messages are suppressed when quiet mode is in effect.
Flags must precede all other parameters to rabbitmqctl.
rabbitmqctl stop
Stops the Erlang node on which RabbitMQ is running. To restart the node follow the instructions for Running the Server in the installation guide.
For example:
rabbitmqctl stop
This command instructs the RabbitMQ node to terminate.
rabbitmqctl stop_app
Stops the RabbitMQ application, leaving the Erlang node running.
This command is typically run prior to performing other
management actions that require the RabbitMQ application
to be stopped, e.g. reset.
For example:
rabbitmqctl stop_app
This command instructs the RabbitMQ node to stop the RabbitMQ application.
rabbitmqctl start_app
Starts the RabbitMQ application.
This command is typically run after performing other
management actions that required the RabbitMQ application
to be stopped, e.g. reset.
For example:
rabbitmqctl start_app
This command instructs the RabbitMQ node to start the RabbitMQ application.
rabbitmqctl status
Displays various information about the RabbitMQ broker, such as whether the RabbitMQ application on the current node, its version number, what nodes are part of the broker, which of these are running.
For example:
rabbitmqctl status
This command displays information about the RabbitMQ broker.
rabbitmqctl reset
rabbitmqctl force_reset
Return a RabbitMQ node to its virgin state.
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.
The force_reset command differs from
reset 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.
For reset and force_reset to
succeed the RabbitMQ application must have been stopped,
e.g. with stop_app.
For example:
rabbitmqctl reset
This command resets the RabbitMQ node.
rabbitmqctl rotate_logs [suffix]
Instruct the RabbitMQ node to rotate the log files.
The RabbitMQ broker will attempt to append the current contents of the log file to the file with name composed of the original name and the suffix. It will create a new file if such a file does not already exist. When no suffix is specified, the empty log file is simply created at the original location; no rotation takes place.
When an error occurs while appending the contents of the old log file, the operation behaves in the same way as if no suffix was specified.
This command might be helpful when you are e.g. writing your own logrotate script and you do not want to restart the RabbitMQ node.
Example:
rabbitmqctl rotate_logs .1
This command instructs the RabbitMQ node to append the current content of the log files to the files with names consisting of the original logs' names and ".1" suffix, e.g. rabbit.log.1. Finally, the old log files are reopened.
rabbitmqctl cluster clusternode ...
Instruct the node to become member of a cluster with the specified nodes.
Cluster nodes can be of two types: disk or ram. Disk nodes replicate data in ram and on disk, 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 and are mainly used for scalability. A cluster must always have at least one disk node.
If the current node is to become a disk node it needs to appear in the cluster node list. Otherwise it becomes a ram node. If the node list is empty or only contains the current node then the node becomes a standalone, i.e. non-clustered, (disk) node.
After executing the cluster command, whenever
the RabbitMQ application is started on the current node it
will attempt to connect to the specified nodes, thus
becoming an active node in the cluster comprising those
nodes (and possibly others).
The list of nodes does not have to contain all the cluster's nodes; a subset is sufficient. Also, clustering generally succeeds as long as at least one of the specified nodes is active. Hence adjustments to the list are only necessary if the cluster configuration is to be altered radically.
For this command to succeed the RabbitMQ application must
have been stopped, e.g. with stop_app. Furthermore,
turning a standalone node into a clustered node requires
the node be reset first,
in order to avoid accidental destruction of data with the
cluster command.
For more details see the clustering guide.
Example:
rabbitmqctl cluster rabbit@tanto hare@elena
This command instructs the RabbitMQ node to join the
cluster with nodes rabbit@tanto and
hare@elena. If the node is one of these then
it becomes a disk node, otherwise a ram node.
rabbitmqctl add_user username password
For example:
rabbitmqctl add_user tonyg changeit
This command instructs the RabbitMQ broker to create a
user named tonyg with (initial) password
changeit.
rabbitmqctl delete_user username
For example:
rabbitmqctl delete_user tonyg
This command instructs the RabbitMQ broker to delete the
user named tonyg.
rabbitmqctl change_password username newpassword
For example:
rabbitmqctl change_password tonyg newpass
This command instructs the RabbitMQ broker to change the
password for the user named tonyg to
newpass.
rabbitmqctl add_vhost vhostpath
For example:
rabbitmqctl add_vhost test
This command instructs the RabbitMQ broker to create a new
virtual host called test.
rabbitmqctl delete_vhost vhostpath
Deleting a virtual host deletes all its exchanges, queues, user mappings and associated permissions.
For example:
rabbitmqctl delete_vhost test
This command instructs the RabbitMQ broker to delete the
virtual host called test.
rabbitmqctl list_vhosts
For example:
rabbitmqctl list_vhosts
This command instructs the RabbitMQ broker to list all virtual hosts.
rabbitmqctl map_user_vhost username vhostpath
For example:
rabbitmqctl map_user_vhost tonyg test
This command instructs the RabbitMQ broker to grant the
user named tonyg access to the virtual host
called test.
rabbitmqctl unmap_user_vhost username vhostpath
For example:
rabbitmqctl unmap_user_vhost tonyg test
This command instructs the RabbitMQ broker to deny the
user named tonyg access to the virtual host
called test.
rabbitmqctl list_user_vhost username
For example:
rabbitmqctl list_user_vhosts tonyg
This command instructs the RabbitMQ broker to list all the
virtual hosts to which the user named tonyg
has been granted access.
rabbitmqctl list_vhost_users vhostpath
For example:
rabbitmqctl list_vhosts_user test
This command instructs the RabbitMQ broker to list all the
users which have been granted access to the virtual host
called test.
The server status queries interrogate the server and return a list of
results with tab-delimited columns. Some queries (list_queues,
list_exchanges and list_bindings) accept an
optional vhost parameter. This parameter, if present, must be
specified immediately after the query.
rabbitmqctl list_queues [-p vhostpath] [queueinfoitem ...]
Returns queue details. Queue details of the / virtual host
are returned if the "-p" flag is absent. The "-p" flag can be used to
override this default.
The queueinfoitem parameter is used to indicate which queue
information items to include in the results. The column order in the
results will match the order of the parameters. If no
queueinfoitems are specified then queue name and depth are
displayed. queueinfoitem can take any value from the list
that follows:
For example:
rabbitmqctl list_queues -p /myvhost messages consumers
This command displays the depth and number of consumers for each
queue of the virtual host named /myvhost.
rabbitmqctl list_exchanges [-p vhostpath] [exchangeinfoitem ...]
Returns exchange details. Exchange details of the / virtual host
are returned if the "-p" flag is absent. The "-p" flag can be used to
override this default.
The exchangeinfoitem parameter is used to indicate which
exchange information items to include in the results. The column order in the
results will match the order of the parameters. If no
exchangeinfoitems are specified then exchange name and type are
displayed. exchangeinfoitem can take any value from the list
that follows:
direct, topic,
fanout]).
For example:
rabbitmqctl list_exchanges -p /myvhost name type
This command displays the name and type for each
exchange of the virtual host named /myvhost.
rabbitmqctl list_bindings [-p vhostpath]
By default the bindings for the / virtual host are
returned. The "-p" flag can be used to override this default.
Each result row will contain an exchange name, routing key, queue
name and binding arguments, in that order. Non-ASCII characters will
be URL-encoded.
rabbitmqctl list_connections
[connectioninfoitem ...]
Returns TCP/IP connection statistics.
The connectioninfoitem parameter is used to indicate
which connection information items to include in the results. The
column order in the results will match the order of the parameters. If
no connectioninfoitems are specified then user, peer
address and peer port are displayed. connectioninfoitem
can take any value from the list that follows:
starting, tuning,
opening, running, closing, closed]).
For example:
rabbitmqctl list_connections send_pend server_port
This command displays the send queue size and server port for each connection.
This section describes additions to the server that are considered experimental.
In versions of the RabbitMQ server prior to version 1.5.0,
it was possible for clients to attempt to store so many
messages within the server that it outgrew the available
memory. With the release of version 1.5.0, an experimental
memory-pressure-detection feature has been added to the
codebase, so that when the server notices available memory
drop below 5% of the total memory available to the system,
it throttles publishers with the channel.flow
AMQP command.
This new feature is disabled by default. To enable it, add
-rabbit memory_alarms true
to your RABBITMQ_SERVER_START_ARGS
environment variable or to the
SERVER_START_ARGS definition in
/etc/default/rabbitmq, as appropriate for
your platform.
The memory threshold at which the flow control is triggered can be adjusted by modifying the
-os_mon system_memory_high_watermark 0.95line in the
rabbitmq-server
/ rabbitmq-server.bat script.
The feature has been tested and found to work on various Linux distributions; there are known issues with Mac OS X. Please report back to the RabbitMQ mailing list your experiences using the feature on your platform!