cmap_keys8
Overview of keys stored in the configuration map
Overview
There are 3 main types of keys stored in CMAP:
* Mapping of values stored in the config file.
* Runtime statistics.
* Other user created values.
In this man page, wild-cards have the usual meaning.
Icmap keys
These keys are in the icmap (default) map
- internal_configuration.*
-
Internal configuration data. All keys in this prefix are read only. It's only useful for getting a list of loaded services.
- logging.*
-
Values read from the configuration file. It's possible to change them at runtime. If subsystem specific configuration is needed, the key must be in the form logging.logger_subsys.SERVICE.key, where SERVICE is upper case name of the service and key is same as in the configuration file. All values are of string type.
- nodelist.*
-
Values are read from the configuration file only (dynamic updates are not allowed). Each node element in the configuration file gets assigned its position starting from zero. So the first node from the config file has nodelist.node.0. prefix. To be a valid entry, each node must have
ring0_addrkey. To change thenodeidkey, use a u32 data type.Local node position is stored in
local_node_poskey (RO), so it's easy to find out nodeid/ring addresses of the local node directly from cmap.
- runtime.blackbox.*
-
Trigger keys for storing fplay data. It's recommended that you use the corosync-blackbox command to change keys in this prefix.
- runtime.force_gather
-
Set to 'yes' to force the processor to move into the GATHER state. This operation is dangerous and is not recommended.
- runtime.config.*
-
Contains the values actually in use by the totem membership protocol. Values here are either taken from the Corosync configuration file, defaults or computed from entries in the config file. For information on individual keys please refer to the man page corosync.conf(5).
- runtime.services.*
-
Prefix with statistics for service engines. Each service has its own
service_idkey in the prefix with the name runtime.services.SERVICE., where SERVICE is the lower case name of the service. Inside the service prefix is the number of messages received and sent by the corosync engine in the format runtime.services.SERVICE.EXEC_CALL.rx and runtime.services.SERVICE.EXEC_CALL.tx, where EXEC_CALL is the internal id of the service call (so for example 3 in cpg service is receive of multicast message from other nodes).
- runtime.totem.members.*
-
Prefix containing members of the totem single ring protocol. Each member keys has format runtime.totem.members.NODEID.KEY, where key is one of:
config_versionConfig version of the member node.
- resources.process.PID.*
-
Prefix created by applications using SAM with CMAP integration. It contains the following keys:
recoveryRecovery policy of the process. Can be one of quit or restart.poll_periodValue passed in sam_initialize as a time_interval.last_updatedLast time SAM received a heartbeat from the client.stateState of the client. Can be one of failed, stopped, running and waiting for quorum.
- uidgid.*
-
Information about users/groups which are allowed to make IPC connections to corosync. Entries loaded from configuration file are stored with uidgid.config.* prefix and are pruned on configuration file reload. Dynamic entries has uidgid.* prefix and a configuration file reload doesn't affect them.
- quorum.cancel_wait_for_all
-
Tells votequorum to cancel waiting for all nodes at cluster startup. Can be used to unblock quorum if notes are known to be down. For pcs use only.
- config.reload_in_progress
-
This value will be set to 1 (or created) when a corosync.conf reload is started, and set to 0 when the reload is completed. This allows interested subsystems to do atomic reconfiguration rather than changing each key. Note that individual add/change/delete notifications will still be sent during a reload.
- config.totemconfig_reload_in_progress
-
This key is similar to
config.totemconfig_reload_in_progressbut changed after the totem config trigger is processed. It is useful (mainly) for situations whennodelist.local_node_posmust be correctly reinstated before anything else.
Stats keys
These keys are in the stats map. All keys in this map are read-only. Modification tracking of individual keys is supported in the stats map, but not prefixes. Add/Delete operations are supported on prefixes though so you can track for new ipc connections or knet interfaces.
- stats.srp.*
-
Prefix containing statistics about totem. Typical key prefixes:
commit_enteredNumber of times the processor entered COMMIT state.commit_token_lostNumber of times the processor lost token in COMMIT state.consensus_timeoutsHow many times the processor timed out forming a consensus about membership.continuous_gatherHow many times the processor was not able to reach consensus.firewall_enabled_or_nic_failureSet to 1 when processor was not able to reach consensus for long time. The usual reason is a badly configured firewall or connection failure.gather_enteredNumber of times the processor entered GATHER state.gather_token_lostNumber of times the processor lost token in GATHER state.mcast_retxNumber of retransmitted messages.mcast_rxNumber of received multicast messages.mcast_txNumber of transmitted multicast messages.memb_commit_token_rxNumber of received commit tokens.memb_commit_token_txNumber of transmitted commit tokens.memb_join_rxNumber of received join messages.memb_join_txNumber of transmitted join messages.memb_merge_detect_rxNumber of received member merge messages.memb_merge_detect_txNumber of transmitted member merge messages.orf_token_rxNumber of received orf tokens.orf_token_txNumber of transmitted orf tokens.recovery_enteredNumber of times the processor entered recovery.recovery_token_lostNumber of times the token was lost in recovery state.rx_msg_droppedNumber of received messages which were dropped because they were not expected (as example multicast message in commit state).token_hold_cancel_rxNumber of received token hold cancel messages.token_hold_cancel_txNumber of transmitted token hold cancel messages.mtt_rx_tokenMean transit time of token in milliseconds. In other words, time between two consecutive token receives.avg_token_workloadAverage time in milliseconds of holding time of token on the current processor.avg_backlog_calcAverage number of not yet sent messages on the current processor.
- stats.knet.nodeX.linkY.*
-
Statistics about the network traffic to and from each node and link when using tke kronosnet transport
connectedWhether the link is connected or notup_countNumber of times this link has changed state to UPdown_countNumber of times this link has changed state to DOWNlatency_ave / latency_max / latency_max Calculated latencies of this link. Note that if there has been no traffic on the link then latency_min will show a very large number.
latency_samplesThe number of samples used to calculate the latency figures, so you have some idea of their precision.rx_data_packets / tx_data_packets The number of packets sent/received on this link
rx_data_bytes / tx_data_bytes The number of bytes sent/received on this link
rx_pmtu_packets / tx_pmtu_packets The number of packets sent/received by the PMTUd subsystem
rx_pmtu_bytes / tx_pmtu_bytes The number of bytes sent/received by the PMTUd subsystem
rx_ping_packets / tx_ping_packets The number of packets sent/received as pings
rx_ping_bytes / tx_ping_bytes The number of bytes sent/received as pings
rx_pong_packets / tx_pong_packets The number of packets sent/received as pongs
rx_pong_bytes / tx_pong_bytes The number of bytes sent/received as pongs
rx_total_packets / tx_total_packets The total number of packets sent/received. The aggregate of all of the above packet stats
rx_total_bytes / tx_total_bytes The total number of bytes sent/received. The aggregate of all of the above bytes stats
tx_data_retries / tx_pmtu_retries / tx_ping_retries / tx_pong_retries / tx_total_retries Number of times a transmit operation had to be retried due to the socket returning EAGAIN
- stats.ipcs.*
-
There is information about total number of active connections from client programs at the time the request was made.
activenumber of closed connections during whole runtime of corosyncclosedTotal number of connections that have been made since corosync was started
- stats.ipcs.ID.*
-
Each IPC connection has a unique ID. This is in the form [[serviceX:][PID:]internal_id.
Typical keys in this prefix are:
proc_nameprocess name of connected process (unavailable on some platforms)dispatchednumber of dispatched messages.invalid_requestnumber of requests made by IPC which are invalid (calling non-existing call, ...).namecontains short name of the IPC connection (unavailable on some platforms).overloadis number of requests which were not processed because of overload.queue_sizecontains the number of messages in the queue waiting for send.recv_retriesis the total number of interrupted receives.requestscontains the number of requests made by IPC.responsesis the number of responses sent to the IPC client.send_retriescontains the total number of interrupted sends.service_idcontains the ID of service which the IPC is connected to.
- stats.clear.*
-
These are write-only keys used to clear the stats for various subsystems
totemClears the pg & srp totem stats.knetClears the knet statsipcClears the ipc statsallClears all of the above stats
Dynamic change user/group permission to use corosync IPC
Is the same as in the configuration file. eg: to add UID 500 use
# corosync-cmapctl -s uidgid.uid.500 u8 1
GID is similar, so to add a GID use
# corosync-cmapctl -s uidgid.gid.500 u8 1
For removal of permissions, simply delete the key
# corosync-cmapctl -d uidgid.gid.500
Releases
2 releases since Debian 9 (Stretch); the text changed 1 time.