RABBITMQCTL(8)

πŸ’– RABBITMQCTL(8) πŸ’–

okay bestie, welcome to the System Manager's Manual ✨ this is rabbitmqctl and she is that girl. let's get into it.


🌸 NAME 🌸

rabbitmqctl β€” the tool for managing RabbitMQ nodes πŸ‡πŸ‘‘


πŸŽ€ SYNOPSIS πŸŽ€

rabbitmqctl [-q] [-s] [-l] [-n node] [-t timeout] command
            [command_options]

that's the whole vibe right there. command + optional command options, we move πŸ’…


πŸ¦‹ DESCRIPTION πŸ¦‹

RabbitMQ is an open-source multi-protocol messaging broker. periodt.

rabbitmqctl is the main command line tool for managing a RabbitMQ server node β€” she rolls with rabbitmq-diagnostics, rabbitmq-upgrade, and the rest of the friend group.

The way she does literally everything: she connects to the target RabbitMQ node on a dedicated CLI tool communication port, and authenticates using a shared secret (that's the cookie file, iykyk).

If the connection failed, or the target node wasn't running, or rabbitmqctl couldn't authenticate to the target node successfully β€” you get diagnostic information displayed. she will tell you what went wrong 🫢

wanna learn more? the RabbitMQ CLI Tools guide is right here: https://www.rabbitmq.com/docs/cli


✨ OPTIONS ✨

  • -n node β€” the default node is "rabbit@target-hostname", where target-hostname is the local host. so 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 the details of configuring a RabbitMQ node.
  • -q, --quiet β€” quiet output mode is selected πŸ”‡ informational messages get reduced when quiet mode is in effect.
  • -s, --silent β€” silent output mode is selected 🀫 informational messages get reduced and table headers are suppressed when silent mode is in effect.
  • --no-table-headers β€” do not output headers for tabular data. no header, no problems ✨
  • --dry-run β€” do not run the command. only print informational messages. it's giving window shopping πŸ›οΈ
  • -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. learn more in the RabbitMQ Clustering guide: https://www.rabbitmq.com/docs/clustering
  • --erlang-cookie cookie β€” shared 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. (putting secrets in your shell history is not the move, bestie.) learn more: https://www.rabbitmq.com/docs/cli

πŸ‘‘ COMMANDS πŸ‘‘

help [-l] [command_name]

Prints usage for all available commands πŸ“–

  • -l, --list-commands β€” list command usages only, without parameter explanation. just the names, keep it snappy πŸ’…
  • 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 🧼✨

she removes the node from any cluster it belongs to, removes all data from the management database (like configured users and vhosts), and deletes all persistent messages. full factory reset energy.

⚠️ for reset and force_reset to succeed, the RabbitMQ application must have been stopped, e.g. with stop_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. so like, don't wait up.

πŸ“ 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: https://www.rabbitmq.com/docs/download

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 pid

Waits 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 count

Waits for count nodes to join the cluster πŸ‘―

for example, to wait for two RabbitMQ nodes to start:

rabbitmqctl await_online_nodes 2

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. power outage chaos 😡

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 (deprecated) 🚨

Forcefully returns a RabbitMQ node to its virgin state.

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. do not just casually hit this one, bestie.

⚠️ the force_reset command is deprecated. it remains available when the Mnesia metadata store is used. it is unsupported with the Khepri metadata store.

for reset and force_reset to succeed the RabbitMQ application must have been stopped, e.g. with stop_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. seriously. no.

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 🫑

okay so when you pass the --offline flag, rabbitmqctl does NOT try to connect to a node like it normally would β€” instead it temporarily becomes the node, just to make the change happen. it's giving "i'll do it myself" energy and honestly? we respect it. this is the move when the node can't even start normally. πŸ™ˆ

the thing is, when that happens, that node becomes the canonical source for cluster metadata (like, which queues exist and everything) β€” even if it wasn't before. so babe, seriously, use this command on the latest node to shut down if at all possible. no cap. ⚠️

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

  • seed-node β€” existing cluster member (the seed node) to cluster with.

instructs the node to become a member of the cluster that the specified node is in. before clustering, the node gets reset, so be careful when using this command, bestie. 😭 and for this command to actually succeed, the RabbitMQ application must have been stopped first, e.g. with stop_app.

after you run join_cluster, 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 the forget_cluster_node command. 🫢

to learn more, see the RabbitMQ Clustering guide: https://www.rabbitmq.com/docs/clustering.


πŸ’– User Management πŸ’–

heads up bestie: all user management commands in rabbitmqctl can only manage users in the internal RabbitMQ database. users from any alternative authentication backends such as LDAP cannot be inspected or managed with those commands. that's a rabbitmqctl. thing. πŸ’…

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 the (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 might still be able to through e.g. SASL EXTERNAL if that's configured for them). πŸ™ˆ

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 it 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).

and 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 β€” the state of the virtual host, one of nodedown, running, stopped.

And if you pass no vhostinfoitems at all? Then babe, you just get the vhost name. That's it. Keep it simple. πŸŽ€

Example time β€” this one tells the broker to list every virtual host:

rabbitmqctl list_vhosts name tracing

πŸ¦‹ set_permissions [-p vhost] user conf write read

  • vhost β€” which virtual host you're granting this user access to; defaults to "/".
  • user β€” the name of the user getting access to that virtual host.
  • conf β€” a regular expression that matches resource names the user gets configure permissions on.
  • write β€” a regular expression matching resource names the user gets write permissions on.
  • read β€” a regular expression matching resource names the user gets read permissions on.

Sets user permissions. Iconic. πŸ’…

So like, this command tells the broker to give the user named "janeway" access to the virtual host called "my-vhost", with configure permissions on every resource whose name starts with "janeway-", plus write and read permissions on all the resources:

rabbitmqctl set_permissions -p my-vhost janeway "^janeway-.*" ".*" ".*"

🌸 set_permissions_globally username conf write read

  • username β€” the name of the user you're granting access to the specified virtual host. (Yes bestie, that's what it says, and we're keeping it.)
  • conf β€” a regular expression matching resource names the user gets configure permissions on.
  • write β€” a regular expression matching resource names the user gets write permissions on.
  • read β€” a regular expression matching resource names the user gets read permissions on.

Sets user permissions in all vhosts. All of them. Every single one. main character energy fr fr. πŸ‘‘

For example, this tells the broker to give the user named "janeway" access to all virtual hosts, with configure permissions on all resources whose names start with "janeway-", and write plus read permissions on all resources:

rabbitmqctl set_permissions_globally janeway "^janeway-.*" ".*" ".*"

πŸ’– set_topic_permissions [-p vhost] user exchange write read

  • vhost β€” the virtual host you're granting the user access to; defaults to "/".
  • user β€” the name of the user these permissions apply to in the target virtual host.
  • exchange β€” the name of the topic exchange the authorisation check gets applied to.
  • 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. πŸŽ€

Example incoming: this one tells the 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 that starts with "janeway-":

rabbitmqctl set_topic_permissions -p my-vhost janeway amq.topic "^janeway-.*" "^janeway-.*"

Topic permissions support variable expansion for these variables: username, vhost, and client_id. Heads up though β€” client_id only gets expanded when you're 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 every running application.


🫢 list_bindings [-p vhost] [bindinginfoitem ...]

Returns binding details. By default you get the bindings for the "/" virtual host β€” the -p flag is how you override that default. Slay.

The bindinginfoitem parameter says which binding info items to include in the results, and the column order in the results matches the order of your parameters. So order matters, bestie. bindinginfoitem can take any of these values:

  • source_name β€” the name of the source of messages the binding is attached to; non-ASCII characters get escaped as in C.
  • source_kind β€” the kind of the source of messages the binding is attached to. Currently always exchange. With non-ASCII characters escaped as in C.
  • destination_name β€” the name of the destination of messages the binding is attached to, with non-ASCII characters escaped as in C.
  • destination_kind β€” the kind of destination of messages the binding is attached to, 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 you don't specify any bindinginfoitems, then every single item above gets displayed. All of them. 🎁

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 info on all current channels β€” the logical containers that execute most AMQP commands. This includes channels that are part of ordinary AMQP connections and channels created by various plug-ins and other extensions. Everybody's here, it's a party. πŸŽ‰

The channelinfoitem parameter says which channel info items to include, and the column order in the results matches the order of the parameters. channelinfoitem can be any of these:

  • pid β€” id of the Erlang process associated with the connection.
  • connection β€” id of the Erlang process associated with the connection the channel belongs to.
  • name β€” a readable name for the channel.
  • number β€” the number of the channel, which uniquely identifies it within a connection.
  • user β€” the username associated with the channel.
  • vhost β€” the 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 that aren't in confirm mode, this stays at 0.
  • prefetch_count β€” the QoS prefetch limit for new consumers, or 0 if it's unlimited.

If you specify no channelinfoitems, then pid, user, consumer_count, and messages_unacknowledged are assumed. Those four, that's the default lineup. ✨

For example, this command displays the connection process and the count of unacknowledged messages for each channel:

rabbitmqctl list_channels connection messages_unacknowledged

🌈 list_ciphers

Lists the cipher suites supported by encoding commands.

For example, this command tells the broker to list all cipher suites supported by encoding commands:

rabbitmqctl list_ciphers

⭐ list_connections [connectioninfoitem ...]

Returns TCP/IP connection statistics.

The connectioninfoitem parameter says which connection info items to include in the results, and the column order in the results matches the order of the parameters. connectioninfoitem can take any value from this list:

  • pid β€” id of the Erlang process associated with the connection.
  • name β€” a readable name for the connection.
  • port β€” server port.
  • host β€” the server's hostname, sourced via reverse DNS. If reverse DNS failed or was turned off, you just get its IP address instead. no drama, just facts. πŸ“‘
  • peer_port β€” the peer's port, simple as.
  • peer_host β€” the peer's hostname, also via reverse DNS. Same deal: if reverse DNS failed or was not enabled, it's the IP address.
  • ssl β€” boolean, is this connection secured with SSL or nah.
  • ssl_protocol β€” the SSL protocol, like "tlsv1".
  • ssl_key_exchange β€” SSL key exchange algorithm, e.g. "rsa".
  • ssl_cipher β€” SSL cipher algorithm, e.g. "aes_256_cbc".
  • ssl_hash β€” SSL hash function, e.g. "sha".
  • peer_cert_subject β€” the subject of the peer's SSL certificate, in RFC4514 form.
  • peer_cert_issuer β€” the issuer of the peer's SSL certificate, in RFC4514 form.
  • peer_cert_serial_number β€” the serial number of the peer's SSL certificate, in hexadecimal form.
  • peer_cert_validity β€” the period for which the peer's SSL certificate is valid.
  • state β€” the connection state, and it's one of these:
    • starting
    • tuning
    • opening
    • running
    • flow
    • blocking
    • blocked
    • closing
    • closed
  • channels β€” how many channels are using this connection.
  • protocol β€” the version of the AMQP protocol in use. currently one of:
    • {0,9,1}
    • {0,8,0}
heads up bestie: if a client requests an AMQP 0-9 connection, we treat it as AMQP 0-9-1. that's just how it is. πŸ’…
  • auth_mechanism β€” the SASL authentication mechanism used, such as "PLAIN".
  • user β€” the username tied to this connection.
  • vhost β€” the virtual hostname, with non-ASCII characters escaped as in C.
  • timeout β€” connection timeout / negotiated heartbeat interval, in seconds.
  • frame_max β€” maximum frame size, in bytes.
  • channel_max β€” maximum number of channels allowed on this connection.
  • client_properties β€” informational properties the client sends over during connection establishment.
  • recv_oct β€” octets received.
  • recv_cnt β€” packets received.
  • send_oct β€” octets send. (yes, that's the original wording, we're keeping it fr)
  • send_cnt β€” packets sent.
  • send_pend β€” send queue size.
  • connected_at β€” the date and time this connection was established, as a timestamp.

If you don't pass any connectioninfoitems, the default lineup is: user, peer host, peer port, time since flow control, and memory block state. that's the default, periodt. ✨

Wanna see it in action? This command displays the send queue size and server port for each connection:

rabbitmqctl list_connections send_pend port

🫢 list_consumers 🫢

rabbitmqctl list_consumers [-p vhost]

Lists consumers, aka the subscriptions to a queue´s message stream. 🌊 Each line it prints out is separated by tab characters and shows:

  • the name of the queue subscribed to,
  • the id of the channel process via which the subscription was created and is managed,
  • the consumer tag, which uniquely identifies the subscription within a channel,
  • a boolean saying whether acknowledgements are expected for messages delivered to this consumer,
  • an integer for the prefetch limit (where 0 means "none"),
  • and any arguments for this consumer.

πŸ¦‹ list_exchanges πŸ¦‹

rabbitmqctl list_exchanges [-p vhost] [exchangeinfoitem ...]

Returns exchange details. πŸ’Œ If the -p flag is absent you get the exchange details of the "/" virtual host β€” that's the default. Use -p to override it.

The exchangeinfoitem parameter tells it which exchange information items to include in the results. The column order in the results matches the order of the parameters you gave. exchangeinfoitem can be any of these:

  • name β€” the name of the exchange, with non-ASCII characters escaped as in C.
  • type β€” the exchange type, such as:
    • direct
    • topic
    • headers
    • fanout
  • durable β€” whether or not the exchange survives server restarts.
  • auto_delete β€” whether the exchange gets deleted automatically when it's no longer used.
  • internal β€” whether the exchange is internal, meaning clients cannot publish to it directly. 🚫
  • arguments β€” exchange arguments.
  • policy β€” the policy name for applying to the exchange.

If you don't specify any exchangeinfoitems, you get the exchange name and type. simple. 🌸

For example, this command displays the name and type for each exchange of the virtual host named "my-vhost":

rabbitmqctl list_exchanges -p my-vhost name type

🌈 list_hashes 🌈

rabbitmqctl list_hashes

Lists the hash functions supported by encoding commands. that's it, that's the whole vibe. πŸ”

For example, this command instructs the RabbitMQ broker to list all hash functions supported by encoding commands:

rabbitmqctl list_hashes

πŸ‘‘ list_queues πŸ‘‘

rabbitmqctl list_queues [-p vhost] [--offline | --online | --local]
        [queueinfoitem ...]

Returns queue details. πŸ“‹ Queue details of the "/" virtual host come back if the -p flag is absent β€” and yeah, the -p flag can override that default.

You can filter which queues get displayed by their status or location using one of these mutually exclusive options (pick one, not all, bestie):

  • --offline β€” list only those durable queues that are not currently available (more specifically, their leader node isn't). πŸ’€
  • --online β€” list queues that are currently available (their leader node is). βœ…
  • --local β€” list only those queues whose leader replica is located on the current node. πŸ“

The queueinfoitem parameter says which queue information items to include in the results, and the column order in the results matches the order of the parameters. queueinfoitem can be any of these:

  • name β€” the name of the queue, with non-ASCII characters escaped as in C.
  • durable β€” whether or not the queue survives server restarts.
  • auto_delete β€” whether the queue is deleted automatically when it's no longer used.
  • arguments β€” queue arguments.
  • policy β€” the name of the user policy applied to the queue.
  • operator_policy β€” the name of the operator policy applied to the queue.
  • effective_policy_definition β€” the effective policy definition for the queue: both the user and operator policy definitions merged together. πŸ«±πŸ»β€πŸ«²πŸ½
  • pid β€” the Erlang process identifier of the queue.
  • owner_pid β€” the id of the Erlang process of the connection which is the exclusive owner of the queue. Empty if the queue is non-exclusive.
  • exclusive β€” True if the queue is exclusive (i.e. it has an owner_pid), false otherwise.
  • exclusive_consumer_pid β€” the id of the Erlang process representing the channel of the exclusive consumer subscribed to this queue. Empty if there's no exclusive consumer.
  • exclusive_consumer_tag β€” the consumer tag of the exclusive consumer subscribed to this queue. Empty if there's no exclusive consumer.
  • messages_ready β€” the number of messages ready to be delivered to clients. πŸ“¬
  • messages_unacknowledged β€” the number of messages delivered to clients but not yet acknowledged.
  • messages β€” the sum of ready and unacknowledged messages, aka the queue depth.
  • messages_ready_ram β€” the number of messages from messages_ready which are resident in ram.
  • messages_unacknowledged_ram β€” how many of the messages_unacknowledged are literally chilling in ram rn. πŸ’Ύ
  • messages_ram β€” the total count of messages hanging out in ram.
  • messages_persistent β€” total number of persistent messages in the queue (ngl this is always 0 for transient queues, that's just how it is).
  • message_bytes β€” the sum of the size of every message body in the queue. heads up bestie, this does not count the message properties (headers included) or any overhead, so it's the bodies only. πŸ’…
  • message_bytes_ready β€” same energy as message_bytes but only counting the ones that are ready to be delivered to clients.
  • message_bytes_unacknowledged β€” again like message_bytes, but only the ones already delivered to clients and not yet acknowledged.
  • message_bytes_ram β€” like message_bytes but only counting messages currently held in RAM.
  • message_bytes_persistent β€” like message_bytes but only counting the persistent ones.
  • head_message_timestamp β€” the timestamp property of the first message in the queue, if it's there at all. lowkey important: timestamps of messages only show up when they're in the paged-in state.
  • disk_reads β€” total number of times messages have been read from disk by this queue since it started.
  • disk_writes β€” total number of times messages have been written to disk by this queue since it started.
  • consumers β€” the number of consumers. simply that. ✨
  • consumer_utilisation β€” fraction of the time (between 0.0 and 1.0) that the queue can immediately deliver messages to consumers. this can be less than 1.0 if consumers are limited by network congestion or by prefetch count. not the queue's fault fr fr.
  • memory β€” bytes of memory the runtime allocated for the queue, including stack, heap, and internal structures. 🧠
  • mirror_pids β€” if the queue is mirrored, this lists the IDs of the mirrors (follower replicas). to learn more, see the RabbitMQ Mirroring guide: https://www.rabbitmq.com/docs/3.13/ha
  • synchronised_mirror_pids β€” if the queue is mirrored, this gives the IDs of the mirrors (follower replicas) that are in sync with the leader replica. to learn more, see the RabbitMQ Mirroring guide: https://www.rabbitmq.com/docs/3.13/ha
  • state β€” the state of the queue. normally "running", but it may be "{syncing, message_count}" if the queue is synchronising.
okay so watch out: queues sitting on cluster nodes that are currently down will show a status of "down" β€” and most other queueinfoitem will be unavailable. πŸ™ˆ
  • type β€” queue type, one of: quorum, stream, classic.

If no queueinfoitem s are specified then queue name and depth are displayed. that's the default, no cap.

For example, this command displays the depth and number of consumers for each queue of the virtual host named "my-vhost":

rabbitmqctl list_queues -p my-vhost messages consumers

list_unresponsive_queues 🫢

list_unresponsive_queues [--local] [--queue-timeout seconds]
       [queueinfoitem ...] [--no-table-headers]

Tests queue leader replicas to respond within the given timeout, and lists the ones that did not respond in time. it's giving "who's ghosting me" energy. πŸ‘€

Displayed queues can be filtered by their status or location using one of the following mutually exclusive options (pick one, not both, bestie):

  • --all β€” list all queues.
  • --local β€” list only those queues whose leader replica is located on the current node.

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. queueinfoitem can take any value from the list that follows:

  • name β€” the name of the queue, with non-ASCII characters escaped as in C.
  • durable β€” whether or not the queue should survive server restarts.
  • auto_delete β€” whether the queue will be deleted automatically when all of its explicit bindings are deleted.
  • arguments β€” queue arguments.
  • policy β€” effective policy name for the queue.
  • pid β€” Erlang process identifier of the leader replica.
  • recoverable_mirrors β€” Erlang process identifiers of the mirror replicas that are considered reachable (available).
  • type β€” queue type, one of: quorum, stream, classic.

For example, this command lists only those unresponsive queues whose leader replica is hosted on the target node:

rabbitmqctl list_unresponsive_queues --local name

ping πŸ“

Checks that the node OS process is up, registered with EPMD, and that CLI tools can authenticate with it. like a lil "u up?" text to your broker.

Example:

rabbitmqctl ping -n rabbit@hostname

report πŸ“‹

Generate a server status report containing a concatenation of all server status information for support purposes. the output should be redirected to a file when it's accompanying a support request. do not just paste 4000 lines into a chat, bestie.

For example, this command creates a server report which may be attached to a support request email:

rabbitmqctl report > server_report.txt

schema_info πŸ—‚οΈ

schema_info [--no-table-headers] [column ...]

Lists schema database tables and their properties.

For example, this command lists the table names and their active replicas:

rabbitmqctl schema_info name active_replicas

status πŸ‘‘

Displays broker status information such as the running applications on the current Erlang node, RabbitMQ and Erlang versions, OS name, and memory and file descriptor statistics. (See the cluster_status command to find out which nodes are clustered and running.) so like, this one is about this node, cluster_status is about the whole squad.

For example, this command displays information about the RabbitMQ broker:

rabbitmqctl status

Runtime Parameters and Policies πŸ’–

Certain features of RabbitMQ (such as the Federation plugin) are controlled by dynamic, cluster-wide parameters. There are 2 kinds of parameters: parameters scoped to a virtual host and global parameters. Each vhost-scoped parameter consists of a component name, a name, and a value. The component name and name are strings, and the value is a valid JSON document. A global parameter consists of a name and value. The name is a string and the value is an arbitrary Erlang data structure. 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.

Policies is a feature built on top of runtime parameters. 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.


clear_global_parameter 🧹

clear_global_parameter name

Clears a global runtime parameter. This is similar to clear_parameter but the key-value pair isn't tied to a virtual host. no vhost strings attached fr.

  • name β€” the name of the global runtime parameter being cleared.

For example, this command clears the global runtime parameter "mqtt_default_vhosts":

rabbitmqctl clear_global_parameter mqtt_default_vhosts

clear_parameter 🧼

clear_parameter [-p vhost] component_name key

Clears a parameter.

  • component_name β€” the name of the component for which the parameter is being cleared.
  • name β€” the name of the parameter being cleared.

For example, this command clears the parameter "node01" for the "federation-upstream" component in the default virtual host:

rabbitmqctl clear_parameter federation-upstream node01

list_global_parameters 🌍

Lists all global runtime parameters. This is similar to list_parameters but the global runtime parameters are not tied to any virtual host.

For example, this command lists all global parameters:

rabbitmqctl list_global_parameters

list_parameters πŸ“œ

list_parameters [-p vhost]

Lists all parameters for a virtual host.

For example, this command lists all parameters in the default virtual host:

rabbitmqctl list_parameters

set_global_parameter ✨

set_global_parameter name value

Sets a global runtime parameter. It's the same energy as set_parameter, except the key-value pair isn't tied to a virtual host β€” it's global, it belongs to everyone, main character of the whole broker. ✨

  • name β€” the name of the global runtime parameter being set.
  • value β€” the value for the global runtime parameter, as a JSON document. In most shells you are very likely to need to quote this, bestie, quote it, save yourself. 🫠

For example, this command sets the global runtime parameter "mqtt_default_vhosts" to the JSON document {"O=client,CN=guest":"/"}:

rabbitmqctl set_global_parameter mqtt_default_vhosts '{"O=client,CN=guest":"/"}'

set_parameter [-p vhost] component_name name value

Sets a parameter. Very demure, very parameter-y. πŸ’…

  • component_name β€” the name of the component for which the parameter is being set.
  • name β€” the name of the parameter being set.
  • value β€” the value for the parameter, as a JSON document. In most shells you are very likely to need to quote this.

For example, this command sets the parameter "node01" for the "federation-upstream" component in the default virtual host to the following JSON "guest":

rabbitmqctl set_parameter federation-upstream node01 '{"uri":"amqp://user:password@server/%2F","ack-mode":"on-publish"}'

list_policies [-p vhost]

Lists all policies for a virtual host. Just, like, all of them. πŸŽ€

For example, this command lists all policies in the default virtual host:

rabbitmqctl list_policies

set_operator_policy [-p vhost] [--priority priority] [--apply-to apply-to] name pattern definition

Sets an operator policy that overrides a subset of arguments in user policies. The arguments are identical to those of set_policy β€” same fit, different crown. πŸ‘‘

Supported arguments are:

  • expires
  • message-ttl
  • max-length
  • max-length-bytes

set_policy [-p vhost] [--priority priority] [--apply-to apply-to] name pattern definition

Sets a policy.

  • name β€” the name of the policy.
  • pattern β€” the regular expression that allows the policy to apply if it matches a resource name.
  • definition β€” the definition of the policy, as a JSON document. In most shells you are very likely to need to quote this.
  • priority β€” the priority of the policy as an integer. Higher numbers indicate greater precedence. The default is 0.
  • apply-to β€” which types of objects this policy should apply to. Possible values are:
    • queues (all queue types, including streams)
    • classic_queues (classic queues only)
    • quorum_queues (quorum queues only)
    • streams (streams only)
    • exchanges
    • all

The default is all.

For example, this command sets the policy "federate-me" in the default virtual host so that built-in exchanges are federated:

rabbitmqctl set_policy federate-me ^amq. '{"federation-upstream-set":"all"}'

clear_policy [-p vhost] name

Clears a policy. Gone. Poof. πŸ¦‹

  • name β€” the name of the policy being cleared.

For example, this command clears the "federate-me" policy in the default virtual host:

rabbitmqctl clear_policy federate-me

clear_operator_policy [-p vhost] name

Clears an operator policy. Arguments are identical to those of clear_policy β€” same rules, different policy tier. πŸ’œ

list_operator_policies [-p vhost]

Lists operator policy overrides for a virtual host. Arguments are identical to those of list_policies.


πŸ‘‘ Virtual hosts πŸ‘‘

Heads up, bestie: rabbitmqctl manages the RabbitMQ internal user database. Permissions for users from any alternative authorisation backend will not be visible to rabbitmqctl. It literally cannot see them, no cap. 🫢

add_vhost vhost [--description desc --tags tags --default-queue-type default-q-type]

  • vhost β€” the name of the virtual host entry to create.
  • desc β€” arbitrary virtual host description, e.g. its purpose, for the operator's convenience.
  • tags β€” a comma-separated list of virtual host tags for the operator's convenience.
  • default-q-type β€” if clients do not specify queue type explicitly, this type will be used. One of: quorum, stream.

Creates a virtual host. Baby's first vhost, iconic. ✨

For example, this command instructs the RabbitMQ broker to create a new virtual host called "project9_dev_18":

rabbitmqctl add_vhost project9_dev_18 --description 'Dev environment no. 18' --tags dev,project9

clear_vhost_limits [-p vhost]

Clears virtual host limits.

For example, this command clears vhost limits in vhost "qa_env":

rabbitmqctl clear_vhost_limits -p qa_env

delete_vhost vhost

  • vhost β€” the name of the virtual host entry to delete.

Deletes a virtual host.

Deleting a virtual host deletes all its exchanges, queues, bindings, user permissions, parameters, and policies. Everything. It's giving scorched earth. πŸ”₯😭

For example, this command instructs the RabbitMQ broker to delete the virtual host called "test":

rabbitmqctl delete_vhost a-vhost

list_vhost_limits [-p vhost] [--global] [--no-table-headers]

Displays configured virtual host limits.

  • --global β€” show limits for all vhosts. Suppresses the -p parameter. (They do not coexist, pick a lane. πŸ’…)

restart_vhost [-p vhost]

  • vhost β€” the name of the virtual host entry to restart, defaulting to "/".

Restarts a failed vhost data stores and queues.

For example, this command instructs the RabbitMQ broker to restart a virtual host called "test":

rabbitmqctl restart_vhost test

set_vhost_limits [-p vhost] definition

Sets virtual host limits.

  • definition β€” the definition of the limits, as a JSON document. In most shells you are very likely to need to quote this.

Recognised limits are:

  • max-connections
  • max-queues

Use a negative value to specify "no limit".

For example, this command limits the maximum number of concurrent connections in vhost "qa_env" to 64:

rabbitmqctl set_vhost_limits -p qa_env '{"max-connections": 64}'

This command limits the maximum number of queues in vhost "qa_env" to 256:

rabbitmqctl set_vhost_limits -p qa_env '{"max-queues": 256}'

This command clears the maximum number of connections limit in vhost "qa_env":

rabbitmqctl set_vhost_limits -p qa_env '{"max-connections": -1}'

This command disables client connections in vhost "qa_env":

rabbitmqctl set_vhost_limits -p qa_env '{"max-connections": 0}'

And like, no shade to the original page, but it literally prints this next bit exactly like this, so here it is in all its unhinged glory, untouched:

] username
] definition

set_user_limits

Sets user limits.

  • username β€” the name of the user to apply limits to.
  • definition β€” the definition of the limits, as a JSON document. In most shells you are very likely to need to quote this.

Recognised limits are:

  • max-connections
  • max-channels

Use a negative value to specify "no limit".

For example, this command limits the maximum number of concurrent connections a user is allowed to open "limited_user" to 64:

rabbitmqctl set_user_limits limited_user '{"max-connections": 64}'

This command limits the maximum number of channels a user is allowed to open on a connection "limited_user" to 16:

rabbitmqctl set_user_limits limited_user '{"max-channels": 16}'

This command clears the maximum number of connections limit for user "limited_user":

rabbitmqctl set_user_limits limited_user '{"max-connections": 0}'

And once again, the source page does this, so we're doing it too, verbatim:

] username
] limit

clear_user_limits

Clears user limits.

  • username β€” the name of the user to clear the limits of.
  • limit β€” the name of the limit or "all" to clear all limits at once.

Recognised limits are:

  • max-connections
  • max-channels

For example, this command clears the maximum connection limits of user "limited_user":

rabbitmqctl clear_user_limits limited_user 'max-connections'

bestie this is the ✨surgical✨ version β€” it dips in and clears just the one limit you name, so limited_user keeps every other limit they had going on. no collateral damage, no drama πŸ’…

rabbitmqctl clear_user_limits limited_user all

and this one? this is the nuclear option πŸ’€ the word all says "clear every single limit on limited_user", so everything goes. iconic, terrifying, very much the point of the command.

trace_off 😴

trace_off [-p vhost]
  • vhost β€” the name of the virtual host where you wanna stop tracing. that's it, that's the whole vibe.

Stops tracing. done and dusted πŸŽ€

trace_on πŸ‘€

trace_on [-p vhost]
  • vhost β€” the name of the virtual host where you wanna start tracing.

Starts tracing. 🫢

heads up bestie!! the trace state is not persistent β€” if the node gets restarted, tracing just quietly reverts to being off. so don't come crying to me when your traces vanish after a reboot, i warned you 😭

βš™οΈ Configuration βš™οΈ

decode πŸ”“

decode value passphrase [--cipher cipher] [--hash hash] [--iterations iterations]
  • value passphrase β€” the value you wanna decrypt (the kind of thing the encode command spits out) plus the passphrase. like so:
rabbitmqctl decode '{encrypted, <<"...">>}' mypassphrase
  • --cipher cipher --hash hash --iterations iterations β€” options that set up your decryption settings. ngl they can be used independently of each other, so mix and match however you need. example time:
rabbitmqctl decode --cipher blowfish_cfb64 --hash sha256 --iterations 10000 '{encrypted,<<"...">>} mypassphrase

encode πŸ”

encode value passphrase [--cipher cipher] [--hash hash] [--iterations iterations]
  • value passphrase β€” the value you wanna encrypt plus the passphrase. for instance:
rabbitmqctl encode '<<"guest">>' mypassphrase
  • --cipher cipher --hash hash --iterations iterations β€” options for your encryption settings. again, usable independently, no strings attached πŸŽ€
rabbitmqctl encode --cipher blowfish_cfb64 --hash sha256 --iterations 10000 '<<"guest">>' mypassphrase

set_cluster_name 🏷️

set_cluster_name name

Sets the cluster name to name. this name is announced to clients when they connect, and the federation and shovel plugins use it to keep track of where a message has been. by default it's derived from the hostname of the first node in the cluster, but you can absolutely change it, main character energy ✨

for example, this sets the cluster name to "london":

rabbitmqctl set_cluster_name london

set_disk_free_limit πŸ’Ύ

set_disk_free_limit disk_limit
  • disk_limit β€” your lower bound limit, either as an integer in bytes, or as a string with a memory unit symbol (peep vm_memory_high_watermark for that), like 512M or 1G. once free disk space actually reaches this limit, boom β€” a disk alarm gets set. ⚠️
set_disk_free_limit mem_relative fraction
  • fraction β€” the limit relative to the total available RAM, as a non-negative floating point number.
careful!! values lower than 1.0 can be dangerous and should be used with actual care, not vibes πŸ™ˆ

set_log_level πŸ“’

set_log_level [log_level]

Sets the log level in the running node.

the supported log_level values are, slay:

  • debug
  • info
  • warning
  • error
  • critical
  • none

example:

rabbitmqctl set_log_level debug

set_vm_memory_high_watermark 🌊

set_vm_memory_high_watermark fraction
  • fraction β€” the new memory threshold fraction where flow control kicks in, as a floating point number greater than or equal to 0.
set_vm_memory_high_watermark [absolute] memory_limit
  • memory_limit β€” the new memory limit where flow control gets triggered, expressed in bytes as an integer greater than or equal to 0, or as a string with a memory unit symbol (like 512M or 1G). the available unit symbols are:
    • k, kiB β€” kibibytes (2^10 bytes)
    • M, MiB β€” mebibytes (2^20 bytes)
    • G, GiB β€” gibibytes (2^30 bytes)
    • kB β€” kilobytes (10^3 bytes)
    • MB β€” megabytes (10^6 bytes)
    • GB β€” gigabytes (10^9 bytes)

🚩 Feature Flags 🚩

enable_feature_flag βœ…

enable_feature_flag feature_flag

Enables a feature flag on the target node. cute, simple, effective πŸ’…

example:

rabbitmqctl enable_feature_flag restart_streams

and you can also enable all the feature flags by specifying "all":

rabbitmqctl enable_feature_flag all

list_feature_flags πŸ“‹

list_feature_flags [column ...]

Lists feature flags. ✨

the supported column values are:

  • name
  • state
  • stability
  • provided_by
  • desc
  • doc_url

example:

rabbitmqctl list_feature_flags name state

πŸ”Œ Connection Operations πŸ”Œ

close_all_connections πŸšͺ

close_all_connections [-p vhost] [--global] [--per-connection-delay delay] [--limit limit] explanation
  • -p vhost β€” the name of the virtual host whose connections should be closed. gets ignored when --global is specified.
  • --global β€” whether to close connections for all vhosts. this one overrides -p.
  • --per-connection-delay delay β€” how long to wait, in milliseconds, after each connection closes.
  • --limit limit β€” the number of connections to close. only works per vhost, and gets ignored when --global is specified.
  • explanation β€” the explanation string.

Instructs the broker to close all connections for the specified vhost, or for the entire RabbitMQ node.

for example, this tells the RabbitMQ broker to close 10 connections on the "qa_env" vhost, passing the explanation "Please close":

rabbitmqctl close_all_connections -p qa_env --limit 10 'Please close'

and this one instructs the broker to close all connections to the node:

rabbitmqctl close_all_connections --global

close_connection βœ‚οΈ

close_connection connectionpid explanation
  • connectionpid β€” the id of the Erlang process associated with the connection you wanna close.
  • explanation β€” the explanation string.

Instructs the broker to close the connection tied to that Erlang process id connectionpid (also peep the list_connections command πŸ‘€), and it passes the explanation string along to the connected client as part of the AMQP connection shutdown protocol.

for example, this instructs the RabbitMQ broker to close the connection associated with the Erlang process id "<rabbit@tanto.4262.0>", passing the explanation "go away" to the connected client:

rabbitmqctl close_connection "<rabbit@tanto.4262.0>" "go away"

πŸ’« Misc πŸ’«

eval πŸ§ͺ

eval expression

Evaluates an Erlang expression on the target node. that's the whole thing, bestie β€” fancy, powerful, and honestly a little unhinged, but we love her πŸ’œ


πŸ“ Queue Operations πŸ“

delete_queue πŸ—‘οΈ

delete_queue queue_name [--if-empty | -e] [--if-unused | -u]
  • queue_name β€” the name of the queue to delete.
  • --if-empty β€” delete the queue only if it's empty (meaning it has no messages ready for delivery).
  • --if-unused β€” delete the queue only if it has no consumers.

Deletes a queue. periodt. πŸ’…

purge_queue 🧹

purge_queue [-p vhost] queue
  • queue β€” the name of the queue to purge.

Purges a queue β€” aka removes all messages in it. a full factory reset for the queue contents, no cap πŸŽ€

✨ PLUGIN COMMANDS ✨

Okay so RabbitMQ plugins can literally extend the rabbitmqctl tool and add brand-new commands when they're enabled. πŸ’… The currently available commands? You can find them in the rabbitmqctl help output. The following commands are added by RabbitMQ plugins that ship in the default distribution:


🚜 Shovel plugin

shovel_status

Prints a list of configured Shovels. Periodt.

delete_shovel [-p vhost] name

Instructs the RabbitMQ node to delete the configured shovel by name. You can toss in -p vhost too, bestie.


🀝 Federation plugin

federation_status [--only-down]

Prints a list of federation links.

  • --only-down β€” Only list federation links that are not running.

Instructs the RabbitMQ node to restart the federation link with the specified link_id.


πŸ¦‹ AMQP 1.0 plugin

list_amqp10_connections [amqp10_connectioninfoitem ...]

Similar to the list_connections command, but returns fields that make sense for AMQP-1.0 connections. The amqp10_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. amqp10_connectioninfoitem can take any value from the list that follows:

  • pid β€” Id of the Erlang process associated with the connection.
  • auth_mechanism β€” SASL authentication mechanism used, such as "PLAIN".
  • host β€” Server hostname obtained via reverse DNS, or its IP address if reverse DNS failed or was turned off.
  • frame_max β€” Maximum frame size (bytes).
  • timeout β€” Connection timeout / negotiated heartbeat interval, in seconds.
  • user β€” Username associated with the connection.
  • state β€” Connection state; one of:
    • starting
    • waiting_amqp0100
    • securing
    • running
    • blocking
    • blocked
    • closing
    • closed
  • recv_oct β€” Octets received.
  • recv_cnt β€” Packets received.
  • send_oct β€” Octets send.
  • send_cnt β€” Packets sent.
  • ssl β€” Boolean indicating whether the connection is secured with SSL.
  • ssl_protocol β€” SSL protocol (e.g. "tlsv1").
  • ssl_key_exchange β€” SSL key exchange algorithm (e.g. "rsa").
  • ssl_cipher β€” SSL cipher algorithm (e.g. "aes_256_cbc").
  • ssl_hash β€” SSL hash function (e.g. "sha").
  • peer_cert_subject β€” The subject of the peer's SSL certificate, in RFC4514 form.
  • peer_cert_issuer β€” The issuer of the peer's SSL certificate, in RFC4514 form.
  • peer_cert_serial_number β€” The serial number of the peer's SSL certificate, in hexadecimal form.
  • peer_cert_validity β€” The period for which the peer's SSL certificate is valid.
  • node β€” The node name of the RabbitMQ node to which the connection is established.

πŸ“‘ MQTT plugin

list_mqtt_connections [mqtt_connectioninfoitem]

Similar to the list_connections command, but returns fields that make sense for MQTT connections. The mqtt_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. mqtt_connectioninfoitem can take any value from the list that follows:

  • host β€” Server hostname obtained via reverse DNS, or its IP address if reverse DNS failed or was turned off.
  • port β€” Server port.
  • peer_host β€” Peer hostname obtained via reverse DNS, or its IP address if reverse DNS failed or was not enabled.
  • peer_port β€” Peer port.
  • protocol β€” MQTT protocol version, which can be one of the following:
    • {'MQTT', N/A}
    • {'MQTT', 3.1.0}
    • {'MQTT', 3.1.1}
  • channels β€” The number of channels using the connection.
  • channel_max β€” Maximum number of channels on this connection.
  • frame_max β€” Maximum frame size (bytes).
  • client_properties β€” Informational properties transmitted by the client during connection establishment.
  • ssl β€” Boolean indicating whether the connection is secured with SSL.
  • ssl_protocol β€” SSL protocol (e.g. "tlsv1").
  • ssl_key_exchange β€” SSL key exchange algorithm (e.g. "rsa").
  • ssl_cipher β€” SSL cipher algorithm (e.g. "aes_256_cbc").
  • ssl_hash β€” SSL hash function (e.g. "sha").
  • conn_name β€” Readable name for the connection.
  • connection_state β€” Connection state; one of:
    • starting
    • running
    • blocked
  • connection β€” Id of the Erlang process associated with the internal amqp direct connection.
  • consumer_tags β€” A tuple of consumer tags for QOS0 and QOS1.
  • message_id β€” The last Packet ID sent in a control message.
  • client_id β€” MQTT client identifier for the connection.
  • clean_sess β€” MQTT clean session flag.
  • will_msg β€” MQTT Will message sent in CONNECT frame.
  • exchange β€” Exchange to route MQTT messages configured in rabbitmq_mqtt application environment.
  • ssl_login_name β€” SSL peer cert auth name
  • retainer_pid β€” Id of the Erlang process associated with retain storage for the connection.
  • user β€” Username associated with the connection.
  • vhost β€” Virtual host name with non-ASCII characters escaped as in C.

decommission_mqtt_node

Before the plugin is disabled on a node, or a node removed from the cluster, it must be decommissioned. 🫑

For example, this command will remove the node rabbit@stringer:

rabbitmqctl decommission_mqtt_node rabbit@stringer

🎧 STOMP plugin

list_stomp_connections [stomp_connectioninfoitem]

Similar to the list_connections command, but returns fields that make sense for STOMP connections. The stomp_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. stomp_connectioninfoitem can take any value from the list that follows:

  • conn_name β€” Readable name for the connection.
  • connection β€” Id of the Erlang process associated with the internal amqp direct connection.
  • connection_state β€” Connection state; one of:
    • running
    • blocking
    • blocked
  • session_id β€” STOMP protocol session identifier
  • channel β€” AMQP channel associated with the connection
  • version β€” Negotiated STOMP protocol version for the connection.
  • implicit_connect β€” Indicates if the connection was established using implicit connect (without CONNECT frame)
  • auth_login β€” Effective username for the connection.
  • auth_mechanism β€” STOMP authorization mechanism. Can be one of:
    • config
    • ssl
    • stomp_headers
  • port β€” Server port.
  • host β€” Server hostname obtained via reverse DNS, or its IP address if reverse DNS failed or was not enabled.
  • peer_port β€” Peer port.
  • peer_host β€” Peer hostname obtained via reverse DNS, or its IP address if reverse DNS failed or was not enabled.
  • protocol β€” STOMP protocol version, which can be one of the following:
    • {'STOMP', 0}
    • {'STOMP', 1}
    • {'STOMP', 2}
  • channels β€” The number of channels using the connection.
  • channel_max β€” Maximum number of channels on this connection.
  • frame_max β€” Maximum frame size (bytes).
  • client_properties β€” Informational properties transmitted by the client during connection
  • ssl β€” Boolean indicating whether the connection is secured with SSL.
  • ssl_protocol β€” TLS protocol (e.g. "tlsv1").
  • ssl_key_exchange β€” TLS key exchange algorithm (e.g. "rsa").
  • ssl_cipher β€” TLS cipher algorithm (e.g. "aes_256_cbc").
  • ssl_hash β€” SSL hash function (e.g. "sha").

πŸ“Š Management agent plugin

reset_stats_db [--all]

Reset the management stats database for the RabbitMQ node.

  • --all β€” Reset the stats database for all nodes in the cluster.

πŸ‘€ SEE ALSO πŸ‘€


πŸ‘‘ AUTHOR πŸ‘‘

The RabbitMQ Team <contact-tanzu-data.pdl@broadcom.com>


πŸ’– That's the whole manual, bestie β€” from the RabbitMQ Server pages, dated June 22, 2023, filed under RABBITMQCTL(8). Periodt. πŸ’–

πŸ“¦ where this page comes from