1CMAP_KEYS(8)      Corosync Cluster Engine Programmer's Manual     CMAP_KEYS(8)
2
3
4

NAME

6       cmap_keys - Overview of keys stored in the Configuration Map
7
8

OVERVIEW

10       There are 3 main types of keys stored in CMAP:
11
12       * Mapping of values stored in the config file.
13
14       * Runtime statistics.
15
16       * Other user created values.
17
18       In this man page, wild-cards have the usual meaning.
19
20

ICMAP KEYS

22       These keys are in the icmap (default) map
23
24       internal_configuration.*
25              Internal  configuration  data.  All keys in this prefix are read
26              only.  It's only useful for getting a list of loaded services.
27
28
29       logging.*
30              Values read from the configuration file. It's possible to change
31              them at runtime.  If subsystem specific configuration is needed,
32              the key must be in the  form  logging.logger_subsys.SERVICE.key,
33              where  SERVICE is upper case name of the service and key is same
34              as in the configuration file. All values are of string type.
35
36
37       nodelist.*
38              Values are  read  from  the  configuration  file  only  (dynamic
39              updates  are  not allowed).  Each node element in the configura‐
40              tion file gets assigned its position starting from zero. So  the
41              first  node from the config file has nodelist.node.0. prefix. To
42              be a valid entry, each node must have ring0_addr key.  To change
43              the nodeid key, use a u32 data type.
44
45              Local  node  position  is  stored in local_node_pos key (RO), so
46              it's easy to find out nodeid/ring addresses of  the  local  node
47              directly from cmap.
48
49
50       runtime.blackbox.*
51              Trigger  keys  for storing fplay data. It's recommended that you
52              use the corosync-blackbox command to change keys in this prefix.
53
54
55       runtime.force_gather
56              Set to 'yes' to force the processor  to  move  into  the  GATHER
57              state.  This operation is dangerous and is not recommended.
58
59
60       runtime.config.*
61              Contains the values actually in use by the totem membership pro‐
62              tocol.  Values here are either taken from the Corosync  configu‐
63              ration  file,  defaults  or  computed from entries in the config
64              file. For information on individual keys please refer to the man
65              page corosync.conf(5).
66
67
68       runtime.services.*
69              Prefix with statistics for service engines. Each service has its
70              own service_id key in the  prefix  with  the  name  runtime.ser‐
71              vices.SERVICE., where SERVICE is the lower case name of the ser‐
72              vice. Inside the  service  prefix  is  the  number  of  messages
73              received  and  sent  by  the  corosync engine in the format run‐
74              time.services.SERVICE.EXEC_CALL.rx   and   runtime.services.SER‐
75              VICE.EXEC_CALL.tx,  where  EXEC_CALL  is  the internal id of the
76              service call (so for example 3 in cpg service is receive of mul‐
77              ticast message from other nodes).
78
79
80       runtime.totem.members.*
81              Prefix  containing  members  of  the totem single ring protocol.
82              Each member keys  has  format  runtime.totem.members.NODEID.KEY,
83              where key is one of:
84
85              config_version Config version of the member node.
86
87
88       resources.process.PID.*
89              Prefix  created by applications using SAM with CMAP integration.
90              It contains the following keys:
91
92              recovery Recovery policy of the process. Can be one of  quit  or
93              restart.
94
95              poll_period Value passed in sam_initialize as a time_interval.
96
97              last_updated Last time SAM received a heartbeat from the client.
98
99              state  State  of the client. Can be one of failed, stopped, run‐
100              ning and waiting for quorum.
101
102
103       uidgid.*
104              Information about users/groups which are  allowed  to  make  IPC
105              connections  to corosync. Entries loaded from configuration file
106              are stored with uidgid.config.* prefix and are pruned on config‐
107              uration  file  reload. Dynamic entries has uidgid.* prefix and a
108              configuration file reload doesn't affect them.
109
110
111       quorum.cancel_wait_for_all
112              Tells votequorum to cancel waiting  for  all  nodes  at  cluster
113              startup.  Can be used to unblock quorum if notes are known to be
114              down. For pcs use only.
115
116
117       config.reload_in_progress
118              This value will be set to 1 (or created)  when  a  corosync.conf
119              reload  is  started,  and set to 0 when the reload is completed.
120              This allows interested subsystems to do  atomic  reconfiguration
121              rather   than   changing   each   key.   Note   that  individual
122              add/change/delete notifications will  still  be  sent  during  a
123              reload.
124
125
126       config.totemconfig_reload_in_progress
127              This key is similar to config.totemconfig_reload_in_progress but
128              changed after the totem config trigger is processed. It is  use‐
129              ful (mainly) for situations when nodelist.local_node_pos must be
130              correctly reinstated before anything else.
131
132

STATS KEYS

134       These keys are in the stats map. All keys in this  map  are  read-only.
135       Modification tracking of individual keys is supported in the stats map,
136       but not prefixes.  Add/Delete  operations  are  supported  on  prefixes
137       though so you can track for new ipc connections or knet interfaces.
138
139       stats.srp.*
140              Prefix containing statistics about totem.  Typical key prefixes:
141
142              commit_entered  Number  of  times  the  processor entered COMMIT
143              state.
144
145              commit_token_lost Number of times the processor  lost  token  in
146              COMMIT state.
147
148              consensus_timeouts  How many times the processor timed out form‐
149              ing a consensus about membership.
150
151              continuous_gather How many times the processor was not  able  to
152              reach consensus.
153
154              firewall_enabled_or_nic_failure  Set to 1 when processor was not
155              able to reach consensus for long time. The  usual  reason  is  a
156              badly configured firewall or connection failure.
157
158              gather_entered  Number  of  times  the  processor entered GATHER
159              state.
160
161              gather_token_lost Number of times the processor  lost  token  in
162              GATHER state.
163
164              mcast_retx Number of retransmitted messages.
165
166              mcast_rx Number of received multicast messages.
167
168              mcast_tx Number of transmitted multicast messages.
169
170              memb_commit_token_rx Number of received commit tokens.
171
172              memb_commit_token_tx Number of transmitted commit tokens.
173
174              memb_join_rx Number of received join messages.
175
176              memb_join_tx Number of transmitted join messages.
177
178              memb_merge_detect_rx Number of received member merge messages.
179
180              memb_merge_detect_tx  Number  of  transmitted  member merge mes‐
181              sages.
182
183              orf_token_rx Number of received orf tokens.
184
185              orf_token_tx Number of transmitted orf tokens.
186
187              recovery_entered Number of times the processor entered recovery.
188
189              recovery_token_lost Number of times the token was lost in recov‐
190              ery state.
191
192              rx_msg_dropped  Number  of  received messages which were dropped
193              because they were not expected (as example multicast message  in
194              commit state).
195
196              token_hold_cancel_rx  Number  of received token hold cancel mes‐
197              sages.
198
199              token_hold_cancel_tx Number of  transmitted  token  hold  cancel
200              messages.
201
202              mtt_rx_token  Mean  transit  time  of  token in milliseconds. In
203              other words, time between two consecutive token receives.
204
205              avg_token_workload Average time in milliseconds of holding  time
206              of token on the current processor.
207
208              avg_backlog_calc  Average number of not yet sent messages on the
209              current processor.
210
211
212       stats.knet.nodeX.linkY.*
213              Statistics about the network traffic to and from each  node  and
214              link when using tke kronosnet transport
215
216              connected Whether the link is connected or not
217
218              up_count Number of times this link has changed state to UP
219
220              down_count Number of times this link has changed state to DOWN
221
222              latency_ave  / latency_max / latency_max Calculated latencies of
223              this link. Note that if there has been no traffic  on  the  link
224              then latency_min will show a very large number.
225
226              latency_samples  The  number  of  samples  used to calculate the
227              latency figures, so you have some idea of their precision.
228
229              rx_data_packets  /  tx_data_packets  The   number   of   packets
230              sent/received on this link
231
232              rx_data_bytes  / tx_data_bytes The number of bytes sent/received
233              on this link
234
235              rx_pmtu_packets  /  tx_pmtu_packets  The   number   of   packets
236              sent/received by the PMTUd subsystem
237
238              rx_pmtu_bytes  / tx_pmtu_bytes The number of bytes sent/received
239              by the PMTUd subsystem
240
241              rx_ping_packets  /  tx_ping_packets  The   number   of   packets
242              sent/received as pings
243
244              rx_ping_bytes  / tx_ping_bytes The number of bytes sent/received
245              as pings
246
247              rx_pong_packets  /  tx_pong_packets  The   number   of   packets
248              sent/received as pongs
249
250              rx_pong_bytes  / tx_pong_bytes The number of bytes sent/received
251              as pongs
252
253              rx_total_packets / tx_total_packets The total number of  packets
254              sent/received. The aggregate of all of the above packet stats
255
256              rx_total_bytes  /  tx_total_bytes  The  total  number  of  bytes
257              sent/received. The aggregate of all of the above bytes stats
258
259              tx_data_retries   /   tx_pmtu_retries   /   tx_ping_retries    /
260              tx_pong_retries  /  tx_total_retries  Number of times a transmit
261              operation had to be retried due to the socket returning EAGAIN
262
263
264       stats.ipcs.*
265              There is information about total number  of  active  connections
266              from  client  programs at the time the request was made.  active
267              number of closed connections during whole  runtime  of  corosync
268              closed  Total  number  of  connections that have been made since
269              corosync was started
270
271
272       stats.ipcs.ID.*
273              Each IPC connection has a unique ID. This is in the form  [[ser‐
274              viceX:][PID:]internal_id.
275
276              Typical keys in this prefix are:
277
278              proc_name process name of connected process (unavailable on some
279              platforms)
280
281              dispatched number of dispatched messages.
282
283              invalid_request number of requests made by IPC which are invalid
284              (calling non-existing call, ...).
285
286              name  contains  short name of the IPC connection (unavailable on
287              some platforms).
288
289              overload is number of requests which were not processed  because
290              of overload.
291
292              queue_size  contains the number of messages in the queue waiting
293              for send.
294
295              recv_retries is the total number of interrupted receives.
296
297              requests contains the number of requests made by IPC.
298
299              responses is the number of responses sent to the IPC client.
300
301              send_retries contains the total number of interrupted sends.
302
303              service_id contains the ID of service which the IPC is connected
304              to.
305
306
307       stats.clear.*
308              These  are  write-only  keys used to clear the stats for various
309              subsystems
310
311              totem Clears the pg & srp totem stats.
312
313              knet Clears the knet stats
314
315              ipc Clears the ipc stats
316
317              all Clears all of the above stats
318
319
320

DYNAMIC CHANGE USER/GROUP PERMISSION TO USE COROSYNC IPC

322       Is the same as in the configuration file. eg: to add UID 500 use
323
324       # corosync-cmapctl -s uidgid.uid.500 u8 1
325
326       GID is similar, so to add a GID use
327
328       # corosync-cmapctl -s uidgid.gid.500 u8 1
329
330       For removal of permissions, simply delete the key
331
332       # corosync-cmapctl -d uidgid.gid.500
333
334
335

SEE ALSO

337       corosync_overview(7), corosync.conf(5), corosync-cmapctl(8)
338
339
340
341corosync Man Page                 2018-10-08                      CMAP_KEYS(8)
Impressum