Provided by: corosync_2.3.3-1ubuntu4_amd64 bug

NAME

       cmap_keys - Overview of keys stored in the Configuration Map

OVERVIEW

       There are roughly 3 types of keys stored in CMAP:

       * Mapping of values stored in config file.

       * Runtime statistics.

       * Other user created values.

       In this man page, wild-cards are used with usual meaning.

KEYS

       internal_configuration.*
              Internal  configuration  data.  This  keys  (whole prefix) is read only.  It's only
              useful for getting list of loaded services.

       logging.*
              Values read from configuration file. It's possible to change them at  runtime.   If
              subsystem    specific    configuration   is   needed,   key   must   be   in   form
              logging.logger_subsys.SERVICE.key, where SERVICE is upper case name of service  and
              key is same as in configuration file. All values are of string type.

       nodelist.*
              Values  read  from configuration file. Each node element in configuration file gets
              assigned it's position starting from zero. So  first  node  from  config  file  has
              nodelist.node.0.  prefix.  To  be  valid entry, each node must have ring0_addr key.
              For change of nodeid key, use u32 data type.

              Local node position is stored in local_node_pos key (RO), so it's easy to find  out
              nodeid/ring addresses of local node directly from cmap.

       runtime.blackbox.*
              Trigger  keys  for  store  fplay  data.  It's  recommended to use corosync-blackbox
              command to change keys in this prefix.

       runtime.connections.*
              There are informations about total number of active connections in given moment  in
              active key, number of closed connections during whole runtime of corosync in closed
              key and informations about each active IPC connection. All keys in this prefix  are
              read-only.

       runtime.connections.ID.*
              Each IPC connection has unique ID. This is in form [[short_name:][PID:]internal_id.
              On some platforms, short_name and PID are not filled and only internal_id is used.

              Typical keys in prefix are:

              client_pid containing PID of IPC connection (unavailable on some platforms).

              dispatched with number of dispatched messages.

              invalid_request is number of requests made by IPC which are invalid  (calling  non-
              existing call, ...).

              name containing short name of IPC connection (unavailable on some platforms).

              overload is number of requests which were not processed because of overload.

              queue_size contains number of messages in queue waiting for send.

              recv_retries is total number of interrupted receives.

              requests contains number of requests made by IPC.

              responses is number of responses sent to IPC client.

              send_retries contains total number of interrupted sends.

              service_id contains ID of service which IPC is connected to.

       runtime.services.*
              Prefix  with  statistics  for service engines. Each service has it's own service_id
              key in prefix with name runtime.services.SERVICE., where SERVICE is lower case name
              of  service.  Inside  service  prefix  is  number  of received and send messages by
              corosync    engine    in    format    runtime.services.SERVICE.EXEC_CALL.rx     and
              runtime.services.SERVICE.EXEC_CALL.tx,  where  EXEC_CALL  is internal id of service
              call (so for example 3 in cpg service is receive of multicast  message  from  other
              nodes).

       runtime.totem.pg.mrp.srp.*
              Prefix  with  statistics  about  totem.  All keys there are read only.  Typical key
              prefixes:

              commit_entered Number of times processor entered COMMIT state.

              commit_token_lost Number of times processor lost token in COMMIT state.

              consensus_timeouts How  many  times  processor  timeouted  making  consensus  about
              membership.

              continuous_gather How many times was processor not able to reach consensus.

              firewall_enabled_or_nic_failure  Set  to  1  when  processor  was not able to reach
              consensus for long time. Usual reason is badly configured  firewall  or  connection
              failure.

              gather_entered Number of times processor entered GATHER state.

              gather_token_lost Number of times processor lost token in GATHER state.

              mcast_retx Number of retransmitted messages.

              mcast_rx Number of received multicast messages.

              mcast_tx Number of transmitted multicast messages.

              memb_commit_token_rx Number of received commit tokens.

              memb_commit_token_tx Number of transmitted commit tokens.

              memb_join_rx Number of received join messages.

              memb_join_tx Number of transmitted join messages.

              memb_merge_detect_rx Number of received member merge messages.

              memb_merge_detect_tx Number of transmitted member merge messages.

              orf_token_rx Number of received orf tokens.

              orf_token_tx Number of transmitted orf tokens.

              recovery_entered Number of times processor entered recovery.

              recovery_token_lost Number of times token was lost in recovery state.

              rx_msg_dropped  Number of received messages which was dropped because they were not
              expected (as example multicast message in commit state).

              token_hold_cancel_rx Number of received token hold cancel messages.

              token_hold_cancel_tx Number of transmitted token hold cancel messages.

              mtt_rx_token Mean transit time of token  in  milliseconds.  In  other  words,  time
              between two consecutive token receives.

              avg_token_workload Average time in milliseconds of holding time of token on current
              processor.

              avg_backlog_calc Average number of not yet sent messages of current processor.

       runtime.totem.pg.mrp.srp.members.*
              Prefix containing members of totem single  ring  protocol.  Each  member  keys  has
              format runtime.totem.pg.mrp.srp.members.NODEID.KEY, where key is one of:

              ip IP address of member. It's stored in format r(RING_ID) ip(IP_ADDRESS).

              join_count  Number  of times processor joined membership with local processor. When
              processor fails and rejoins again, this value is incremented.

              status Status of processor. Can be one of joined and left.

              config_version Config version of member node.

       resources.process.PID.*
              Prefix created by applications  using  SAM  with  CMAP  integration.   It  contains
              following keys:

              recovery Recovery policy of process. Can be one of quit or restart.

              poll_period Value passed in sam_initialize as time_interval.

              last_updated Last time when SAM received heartbeat from client.

              state  State  of  client.  Can  be  one of failed, stopped, running and waiting for
              quorum.

       uidgid.*
              Informations about users/groups which are allowed to do IPC connection to corosync.

       config.reload_in_progress
              This value will be set to 1 (or created) when 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.

DYNAMIC CHANGE USER/GROUP PERMISSION TO USE COROSYNC IPC

       Is very same as in configuration file. To add UID 500 use

       # corosync-cmapctl -s uidgid.uid.500 u8 1

       GID is similar, so to add GID use

       # corosync-cmapctl -s uidgid.gid.500 u8 1

       For removal of permission, simply delete key

       # corosync-cmapctl -d uidgid.gid.500

DYNAMIC ADD/REMOVE OF UDPU NODE

       We  will  need to add node with address 10.34.38.108 and nodeid 3. This node is called NEW
       and it's not running corosync yet.

       * Find a node position in node list which  is  not  used  yet.  It's  recommended  to  use
       highest_number + 1. Let's say output of corosync-cmapctl looks like:

       nodelist.local_node_pos (u32) = 1
       nodelist.node.0.nodeid (u32) = 1
       nodelist.node.0.ring0_addr (str) = 10.34.38.106
       nodelist.node.1.nodeid (u32) = 2
       nodelist.node.1.ring0_addr (str) = 10.34.38.107

       So next node position will be 2.

       * Add all entries needed for node on all running nodes, as:

       # corosync-cmapctl -s nodelist.node.2.nodeid u32 3
       # corosync-cmapctl -s nodelist.node.2.ring0_addr str 10.34.38.108

       Always  add  ring0_addr key as last. Corosync engine on all nodes should reply with notice
       [TOTEM ] adding new UDPU member {10.34.38.108} message.

       * Add node information to configuration file on all nodes so it will  survive  restart  of
       corosync.

       * Copy and edit configuration file to NEW node.

       * Start corosync on NEW node.

       Removal of UDPU node is very similar slightly reversed action, so

       * Stop corosync old OLD node.

       * Remove relevant entries from cmap on all nodes.

       * Change configuration file on all nodes.

SEE ALSO

       corosync_overview(8), corosync.conf(5), corosync-cmapctl(8)