rabbitmqctl.8
NAME
rabbitmqctl
— tool for managing RabbitMQ nodes
SYNOPSIS
rabbitmqctl | [-q ] [-s ] [-l ] [-n node] [-t timeout] command [command_options] |
DESCRIPTION
RabbitMQ is an open-source multi-protocol messaging broker.
rabbitmqctl
is the main command line tool for managing a RabbitMQ server node, together with rabbitmq-diagnostics
, rabbitmq-upgrade
, and others.
It performs all actions by connecting to the target RabbitMQ node on a dedicated CLI tool communication port and authenticating using a shared secret (known as the cookie file).
Diagnostic information is displayed if the connection failed, the target node was not running, or rabbitmqctl
could not authenticate to the target node successfully.
To learn more, see the RabbitMQ CLI Tools guide
OPTIONS
-n
node- The default node is "rabbit@target-hostname", where target-hostname is the local host. On a host named "myserver.example.com", the node name will usually be "rabbit@myserver" (unless
RABBITMQ_NODENAME
has been overridden, in which case you'll need to use --longnames
). The output of "hostname -s" is usually the correct hostname to use after the "@" sign. See rabbitmq-server(8) for details of configuring a RabbitMQ node.
-q
,--quiet
- Quiet output mode is selected. Informational messages are reduced when quiet mode is in effect.
-s
,--silent
- Silent output mode is selected. Informational messages are reduced and table headers are suppressed when silent mode is in effect.
--no-table-headers
- Do not output headers for tabular data.
--dry-run
- Do not run the command. Only print informational messages.
-t
timeout,--timeout
timeout- Operation timeout in seconds. Not all commands support timeouts. The default is
infinity
. -l
,--longnames
Must be specified when the cluster is configured to use long (FQDN) node names. To learn more, see the RabbitMQ Clustering guide
--erlang-cookie
cookieShared secret to use to authenticate to the target node. Prefer using a local file or the
RABBITMQ_ERLANG_COOKIE
environment variable instead of specifying this option on the command line. To learn more, see the RabbitMQ CLI Tools guide
COMMANDS
help
[-l
] [command_name]Prints usage for all available commands.
-l
,--list-commands
- List command usages only, without parameter explanation.
- command_name
- Prints usage for the specified command.
version
Displays CLI tools version
Nodes
await_startup
Waits for the RabbitMQ application to start on the target node
For example, to wait for the RabbitMQ application to start:
rabbitmqctl await_startup
reset
Returns 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.
For
reset
andforce_reset
to succeed the RabbitMQ application must have been stopped, e.g. withstop_app
.For example, to reset the RabbitMQ node:
rabbitmqctl reset
rotate_logs
Instructs the RabbitMQ node to perform internal log rotation.
Log rotation is performed according to the logging settings specified in the configuration file. The rotation operation is asynchronous, there is no guarantee that it will complete before this command returns.
Note that there is no need to call this command in case of external log rotation (e.g. from logrotate(8)).
For example, to initial log rotation:
rabbitmqctl rotate_logs
shutdown
Shuts down the node, both RabbitMQ and its runtime. The command is blocking and will return after the runtime process exits. If RabbitMQ fails to stop, it will return a non-zero exit code. This command infers the OS PID of the target node and therefore can only be used to shut down nodes running on the same host (or broadly speaking, in the same operating system, e.g. in the same VM or container)
Unlike the stop command, the shutdown command:
does not require a pid_file to wait for the runtime process to exit
returns a non-zero exit code if the RabbitMQ node is not running
For example, this will shut down a local RabbitMQ node running with the default node name:
rabbitmqctl shutdown
start_app
Starts the RabbitMQ application.
This command is typically run after performing other management actions that require the RabbitMQ application to be stopped, e.g.
reset
.For example, to instruct the RabbitMQ node to start the RabbitMQ application:
rabbitmqctl start_app
stop
[pid_file]Stops the Erlang node on which RabbitMQ is running. To restart the node follow the instructions for "Running the Server" in the installation guide.
If a pid_file is specified, also waits for the process specified there to terminate. See the description of the
wait
command for details on this file.For example, to instruct the RabbitMQ node to terminate:
rabbitmqctl stop
stop_app
Stops the RabbitMQ application, leaving the runtime (Erlang VM) running.
This command is typically run before performing other management actions that require the RabbitMQ application to be stopped, e.g.
reset
.For example, to instruct the RabbitMQ node to stop the RabbitMQ application:
rabbitmqctl stop_app
wait
pid_file,wait
--pid
pidWaits for the RabbitMQ application to start.
This command will wait for the RabbitMQ application to start at the node. It will wait for the pid file to be created if pidfile is specified, then for a process with a pid specified in the pid file or the
--pid
argument, and then for the RabbitMQ application to start in that process. It will fail if the process terminates without starting the RabbitMQ application.If the specified pidfile is not created or the erlang node is not started within
--timeout
the command will fail. The default timeout is 10 seconds.A suitable pid file is created by the rabbitmq-server(8) script. By default, this is located in the Mnesia directory. Modify the
RABBITMQ_PID_FILE
environment variable to change the location.For example, this command will return when the RabbitMQ node has started up:
rabbitmqctl wait /var/run/rabbitmq/pid
Cluster management
await_online_nodes
countWaits for count nodes to join the cluster
For example, to wait for two RabbitMQ nodes to start:
rabbitmqctl await_online_nodes 2
change_cluster_node_type
typeChanges the type of the cluster node.
The type must be one of the following:
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.
For example, this command will turn a RAM node into a disc node:
rabbitmqctl change_cluster_node_type disc
cluster_status
Displays all the nodes in the cluster grouped by node type, together with the currently running nodes.
For example, this command displays the nodes in the cluster:
rabbitmqctl cluster_status
force_boot
Ensures that the node will start next time, even if it was not the last to shut down.
Normally when you shut down a RabbitMQ cluster altogether, the first node you restart should be the last one to go down, since it may have seen things happen that other nodes did not. But sometimes that's not possible: for instance, if the entire cluster loses power then all nodes may think they were not the last to shut down.
In such a case you can invoke
force_boot
while the node is down. This will tell the node to unconditionally start the next time you ask it. Any changes to the cluster after this node shut down will be lost.If the last node to go down is permanently lost then you should use
forget_cluster_node
--offline
instead of this command, as it will ensure that mirrored queues whose leader replica was on the lost node get promoted.For example, this will force the node not to wait for other nodes the next time it is started:
rabbitmqctl force_boot
force_reset
Forcefully returns a RabbitMQ node to its virgin state.
The
force_reset
command differs fromreset
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
andforce_reset
to succeed the RabbitMQ application must have been stopped, e.g. withstop_app
.For example, to reset the RabbitMQ node:
rabbitmqctl force_reset
forget_cluster_node
[--offline
]--offline
- 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.
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
--offline
flag.When using the
--offline
flag ,rabbitmqctl
will not attempt to connect to a node as normal; instead it will temporarily become the node in order to make the change. This is useful if the node cannot be started normally. In this case, the node will become the canonical source for cluster metadata (e.g. which queues exist), even if it was not before. Therefore you should use this command on the latest node to shut down if at all possible.For example, this command will remove the node "rabbit@stringer" from the node "hare@mcnulty":
rabbitmqctl -n hare@mcnulty forget_cluster_node rabbit@stringer
join_cluster
seed-node [--ram
]- seed-node
- Existing cluster member (seed node) to cluster with.
--ram
- If provided, the node will join the cluster as a RAM node. RAM node use is discouraged. Use only if you understand why exactly you need to use them.
Instructs 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
stop_app
.Cluster nodes can be of two types: disc or RAM. Disc 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 (except for queue contents, which can reside on disk 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.
The node will be a disc node by default. If you wish to create a RAM node, provide the
--ram
flag.After executing the
join_cluster
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.To leave a cluster,
reset
the node. You can also remove nodes remotely with theforget_cluster_node
command.For example, this command instructs the RabbitMQ node to join the cluster that "hare@elena" is part of, as a ram node:
rabbitmqctl join_cluster hare@elena --ram
To learn more, see the RabbitMQ Clustering guide.
User Management
Note that all user management commands rabbitmqctl
only can manage users in the internal RabbitMQ database. Users from any alternative authentication backends such as LDAP cannot be inspected or managed with those commands. rabbitmqctl
.
add_user
username password- username
- The name of the user to create.
- password
- The password the created user will use to log in to the broker.
For example, this command instructs the RabbitMQ broker to create a (non-administrative) user named "janeway" with (initial) password "changeit":
rabbitmqctl add_user janeway changeit
authenticate_user
username password- username
- The name of the user.
- password
- The password of the user.
For example, this command instructs the RabbitMQ broker to authenticate the user named "janeway" with the password "verifyit":
rabbitmqctl authenticate_user janeway verifyit
change_password
username newpassword- username
- The name of the user whose password is to be changed.
- newpassword
- The new password for the user.
For example, this command instructs the RabbitMQ broker to change the password for the user named "janeway" to "newpass":
rabbitmqctl change_password janeway newpass
clear_password
username- username
- The name of the user whose password is to be cleared.
For example, this command instructs the RabbitMQ broker to clear the password for the user named "janeway":
rabbitmqctl clear_password janeway
This user now cannot log in with a password (but may be able to through e.g. SASL EXTERNAL if configured).
hash_password
plaintext- plaintext
- The plaintext password to hash
Hashes a plaintext password according to the currently configured password hashing algorithm
delete_user
username- username
- The name of the user to delete.
For example, this command instructs the RabbitMQ broker to delete the user named "janeway":
rabbitmqctl delete_user janeway
list_users
Lists users. Each result row will contain the user name followed by a list of the tags set for that user.
For example, this command instructs the RabbitMQ broker to list all users:
rabbitmqctl list_users
set_user_tags
username [tag ...]- username
- The name of the user whose tags are to be set.
- tag
- Zero, one or more tags to set. Any existing tags will be removed.
For example, this command instructs the RabbitMQ broker to ensure the user named "janeway" is an administrator:
rabbitmqctl set_user_tags janeway administrator
This has no effect when the user authenticates using a messaging protocol, but can be used to permit the user to manage users, virtual hosts and permissions when the user logs in via some other means (for example with the management plugin).
This command instructs the RabbitMQ broker to remove any tags from the user named "janeway":
rabbitmqctl set_user_tags janeway
Access control
clear_permissions
[-p
vhost] username- vhost
- The name of the virtual host to which to deny the user access, defaulting to "/".
- username
- The name of the user to deny access to the specified virtual host.
Sets user permissions.
For example, this command instructs the RabbitMQ broker to deny the user named "janeway" access to the virtual host called "my-vhost":
rabbitmqctl clear_permissions -p my-vhost janeway
clear_topic_permissions
[-p
vhost] username [exchange]- vhost
- The name of the virtual host to which to clear the topic permissions, defaulting to "/".
- username
- The name of the user to clear topic permissions to the specified virtual host.
- exchange
- The name of the topic exchange to clear topic permissions, defaulting to all the topic exchanges the given user has topic permissions for.
Clear user topic permissions.
For example, this command instructs the RabbitMQ broker to remove topic permissions for the user named "janeway" for the topic exchange "amq.topic" in the virtual host called "my-vhost":
rabbitmqctl clear_topic_permissions -p my-vhost janeway amq.topic
list_permissions
[-p
vhost]- vhost
- The name of the virtual host for which to list the users that have been granted access to it, and their permissions. Defaults to "/".
Lists permissions in a virtual host.
For example, this command instructs the RabbitMQ broker to list all the users who have been granted access to the virtual host called "my-vhost", and the permissions they have for operations on resources in that virtual host. Note that an empty string means no permissions are granted:
rabbitmqctl list_permissions -p my-vhost
list_topic_permissions
[-p
vhost]- vhost
- The name of the virtual host for which to list the user's topic permissions. Defaults to "/".
Lists topic permissions in a virtual host.
For example, this command instructs the RabbitMQ broker to list all the users who have been granted topic permissions in the virtual host called "my-vhost:"
rabbitmqctl list_topic_permissions -p my-vhost
list_user_permissions
username- username
- The name of the user for which to list the permissions.
Lists user permissions.
For example, this command instructs the RabbitMQ broker to list all the virtual hosts to which the user named "janeway" has been granted access, and the permissions the user has for operations on resources in these virtual hosts:
rabbitmqctl list_user_permissions janeway
list_user_topic_permissions
username- username
- The name of the user for which to list the topic permissions.
Lists user topic permissions.
For example, this command instructs the RabbitMQ broker to list all the virtual hosts to which the user named "janeway" has been granted access, and the topic permissions the user has in these virtual hosts:
rabbitmqctl list_user_topic_permissions janeway
list_vhosts
[vhostinfoitem ...]Lists virtual hosts.
The vhostinfoitem 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. vhostinfoitem can take any value from the list that follows:
name
- The name of the virtual host with non-ASCII characters escaped as in C.
tracing
- Whether tracing is enabled for this virtual host.
default_queue_type
- Default queue type for this vhost.
description
- Virtual host description.
tags
- Virtual host tags.
cluster_state
- Virtual host state: nodedown, running, stopped.
If no vhostinfoitem s are specified then the vhost name is displayed.
For example, this command instructs the RabbitMQ broker to list all virtual hosts:
rabbitmqctl list_vhosts name tracing
set_permissions
[-p
vhost] user conf write read- vhost
- The name of the virtual host to which to grant the user access, defaulting to "/".
- user
- The name of the user to grant access to the specified virtual host.
- conf
- A regular expression matching resource names for which the user is granted configure permissions.
- write
- A regular expression matching resource names for which the user is granted write permissions.
- read
- A regular expression matching resource names for which the user is granted read permissions.
Sets user permissions.
For example, this command instructs the RabbitMQ broker to grant the user named "janeway" access to the virtual host called "my-vhost", with configured permissions on all resources whose names start with "janeway-", and write and read permissions on all resources:
rabbitmqctl set_permissions -p my-vhost janeway "^janeway-." "." ".*"
set_permissions_globally
username conf write read- username
- The name of the user to grant access to the specified virtual host.
- conf
- A regular expression matching resource names for which the user is granted configure permissions.
- write
- A regular expression matching resource names for which the user is granted write permissions.
- read
- A regular expression matching resource names for which the user is granted read permissions.
Sets user permissions in all vhosts.
For example, this command instructs the RabbitMQ broker to grant the user named "janeway" access to all virtual hosts with configure permissions on all resources whose names starts with "janeway-", and write and read permissions on all resources:
rabbitmqctl set_permissions_globally janeway "^janeway-." "." ".*"
set_topic_permissions
[-p
vhost] user exchange write read- vhost
- The name of the virtual host to which to grant the user access, defaulting to "/".
- user
- The name of the user the permissions apply to in the target virtual host.
- exchange
- The name of the topic exchange to which the authorisation check will be applied.
- write
- A regular expression matching the routing key of the published message.
- read
- A regular expression matching the routing key of the consumed message.
Sets user topic permissions.
For example, this command instructs the RabbitMQ broker to let the user named "janeway" publish and consume messages going through the "amp.topic" exchange of the "my-vhost" virtual host with a routing key starting with "janeway-":
rabbitmqctl set_topic_permissions -p my-vhost janeway amq.topic "^janeway-." "^janeway-."
Topic permissions support variable expansion for the following variables: username, vhost, and client_id. Note that client_id is expanded only when using MQTT. The previous example could be made more generic by using "^{username}-.*":
rabbitmqctl set_topic_permissions -p my-vhost janeway amq.topic "^{username}-." "^{username}-."
Monitoring, observability and health checks
environment
Displays the name and value of each variable in the application environment for each running application.
list_bindings
[-p
vhost] [bindinginfoitem ...]Returns binding details. By default, the bindings for the "/" virtual host are returned. The
-p
flag can be used to override this default.The bindinginfoitem parameter is used to indicate which binding information items to include in the results. The column order in the results will match the order of the parameters. bindinginfoitem can take any value from the list that follows:
source_name
- The name of the source of messages to which the binding is attached. With non-ASCII characters escaped as in C.
source_kind
- The kind of the source of messages to which the binding is attached. Currently always exchange. With non-ASCII characters escaped as in C.
destination_name
- The name of the destination of messages to which the binding is attached. With non-ASCII characters escaped as in C.
destination_kind
- The kind of destination of messages to which the binding is attached. With non-ASCII characters escaped as in C.
routing_key
- The binding's routing key with non-ASCII characters escaped as in C.
arguments
- The binding's arguments.
If no bindinginfoitem s are specified then all the above items are displayed.
For example, this command displays the exchange name and queue name of the bindings in the virtual host named "my-vhost"
rabbitmqctl list_bindings -p my-vhost exchange_name queue_name
list_channels
[channelinfoitem ...]Returns information on all current channels, the logical containers executing most AMQP commands. This includes channels that are part of ordinary AMQP connections and channels created by various plug-ins and other extensions.
The channelinfoitem parameter is used to indicate which channel information items to include in the results. The column order in the results will match the order of the parameters. channelinfoitem can take any value from the list that follows:
pid
- Id of the Erlang process associated with the connection.
connection
- Id of the Erlang process associated with the connection to which the channel belongs.
name
- Readable name for the channel.
number
- The number of the channel uniquely identifying it within a connection.
user
- The username associated with the channel.
vhost
- Virtual host in which the channel operates.
transactional
- True if the channel is in transactional mode, false otherwise.
confirm
- True if the channel is in confirm mode, false otherwise.
consumer_count
- The number of logical AMQP consumers retrieving messages via the channel.
messages_unacknowledged
- The number of messages delivered via this channel but not yet acknowledged.
messages_uncommitted
- The number of messages received in an as-yet uncommitted transaction.
acks_uncommitted
- The number of acknowledgements received in an as-yet uncommitted transaction.
messages_unconfirmed
- The number of not yet confirmed published messages. On channels not in confirm mode, this remains 0.
prefetch_count
- QoS prefetch limit for new consumers, 0 if unlimited.
global_prefetch_count
- QoS prefetch limit for the entire channel, 0 if unlimited.
If no channelinfoitem s are specified then pid, user, consumer_count, and messages_unacknowledged are assumed.
For example, this command displays the connection process and count of unacknowledged messages for each channel:
rabbitmqctl list_channels connection messages_unacknowledged
list_ciphers
Lists cipher suites supported by encoding commands.
For example, this command instructs the RabbitMQ broker to list all cipher suites supported by encoding commands:
rabbitmqctl list_ciphers
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. connectioninfoitem can take any value from the list that follows:
pid
- Id of the Erlang process associated with the connection.
name