1COROSYNC_CONF(5) Corosync Cluster Engine Programmer's Manual COROSYNC_CONF(5)
2
6 corosync.conf - corosync executive configuration file
7
10 /etc/corosync/corosync.conf
11
14 The corosync.conf instructs the corosync executive about various param‐
15 eters needed to control the corosync executive. Empty lines and lines
16 starting with # character are ignored. The configuration file consists
17 of bracketed top level directives. The possible directive choices are:
18 totem { }
21 This top level directive contains configuration options for the
22 totem protocol.
23 logging { }
25 This top level directive contains configuration options for log‐
26 ging.
27 quorum { }
29 This top level directive contains configuration options for quo‐
30 rum.
31 nodelist { }
33 This top level directive contains configuration options for
34 nodes in cluster.
35 system { }
37 This top level directive contains configuration options related
38 to system.
39 resources { }
41 This top level directive contains configuration options for
42 resources.
43 The interface sub-directive of totem is optional for UDP and knet
46 transports.
47 For knet, multiple interface subsections define parameters for each
49 knet link on the system.
50 For UDPU an interface section is not needed and it is recommended that
52 the nodelist is used to define cluster nodes.
53 linknumber
56 This specifies the link number for the interface. When using
57 the knet protocol, each interface should specify separate link
58 numbers to uniquely identify to the membership protocol which
59 interface to use for which link. The linknumber must start at
60 0. For UDP the only supported linknumber is 0.
61 knet_link_priority
64 This specifies the priority for the link when knet is used in
65 'passive' mode. (see link_mode below)
66 knet_ping_interval
69 This specifies the interval between knet link pings.
70 knet_ping_interval and knet_ping_timeout are a pair, if one is
71 specified the other should be too, otherwise one will be calcu‐
72 lated from the token timeout and one will be taken from the con‐
73 fig file. (default is token timeout / (knet_pong_count*2))
74 knet_ping_timeout
77 If no ping is received within this time, the knet link is
78 declared dead. knet_ping_interval and knet_ping_timeout are a
79 pair, if one is specified the other should be too, otherwise one
80 will be calculated from the token timeout and one will be taken
81 from the config file. (default is token timeout /
82 knet_pong_count)
83 knet_ping_precision
86 How many values of latency are used to calculate the average
87 link latency. (default 2048 samples)
88 knet_pong_count
91 How many valid ping/pongs before a link is marked UP. (default
92 5)
93 knet_transport
96 Which IP transport knet should use. valid values are "sctp" or
97 "udp". (default: udp)
98 bindnetaddr (udp only)
101 This specifies the network address the corosync executive should
102 bind to when using udp.
103 bindnetaddr (udp only) should be an IP address configured on the
105 system, or a network address.
106 For example, if the local interface is 192.168.5.92 with netmask
108 255.255.255.0, you should set bindnetaddr to 192.168.5.92 or
109 192.168.5.0. If the local interface is 192.168.5.92 with net‐
110 mask 255.255.255.192, set bindnetaddr to 192.168.5.92 or
111 192.168.5.64, and so forth.
112 This may also be an IPV6 address, in which case IPV6 networking
114 will be used. In this case, the exact address must be specified
115 and there is no automatic selection of the network interface
116 within a specific subnet as with IPv4.
117 If IPv6 networking is used, the nodeid field in nodelist must be
119 specified.
120 broadcast (udp only)
123 This is optional and can be set to yes. If it is set to yes,
124 the broadcast address will be used for communication. If this
125 option is set, mcastaddr should not be set.
126 mcastaddr (udp only)
129 This is the multicast address used by corosync executive. The
130 default should work for most networks, but the network adminis‐
131 trator should be queried about a multicast address to use.
132 Avoid 224.x.x.x because this is a "config" multicast address.
133 This may also be an IPV6 multicast address, in which case IPV6
135 networking will be used. If IPv6 networking is used, the nodeid
136 field in nodelist must be specified.
137 It's not necessary to use this option if cluster_name option is
139 used. If both options are used, mcastaddr has higher priority.
140 mcastport (udp only)
143 This specifies the UDP port number. It is possible to use the
144 same multicast address on a network with the corosync services
145 configured for different UDP ports. Please note corosync uses
146 two UDP ports mcastport (for mcast receives) and mcastport - 1
147 (for mcast sends). If you have multiple clusters on the same
148 network using the same mcastaddr please configure the mcastports
149 with a gap.
150 ttl (udp only)
153 This specifies the Time To Live (TTL). If you run your cluster
154 on a routed network then the default of "1" will be too small.
155 This option provides a way to increase this up to 255. The valid
156 range is 0..255.
157 Within the totem directive, there are seven configuration options of
160 which one is required, five are optional, and one is required when IPV6
161 is configured in the interface subdirective. The required directive
162 controls the version of the totem configuration. The optional option
163 unless using IPV6 directive controls identification of the processor.
164 The optional options control secrecy and authentication, the network
165 mode of operation and maximum network MTU field.
166 version
169 This specifies the version of the configuration file. Currently
170 the only valid version for this directive is 2.
171 clear_node_high_bit This configuration option is optional and is only
174 relevant when no nodeid is specified. Some corosync clients require a
175 signed 32 bit nodeid that is greater than zero however by default
176 corosync uses all 32 bits of the IPv4 address space when generating a
177 nodeid. Set this option to yes to force the high bit to be zero and
178 therefore ensure the nodeid is a positive signed 32 bit integer.
179 WARNING: Cluster behavior is undefined if this option is enabled on
181 only a subset of the cluster (for example during a rolling upgrade).
182 crypto_model
185 This specifies which cryptographic library should be used by
186 knet. Options are nss and openssl.
187 The default is nss.
189 crypto_hash
192 This specifies which HMAC authentication should be used to
193 authenticate all messages. Valid values are none (no authentica‐
194 tion), md5, sha1, sha256, sha384 and sha512. Encrypted transmis‐
195 sion is only supported for the knet transport.
196 The default is none.
198 crypto_cipher
201 This specifies which cipher should be used to encrypt all mes‐
202 sages. Valid values are none (no encryption), aes256, aes192,
203 aes128 and 3des. Enabling crypto_cipher, requires also enabling
204 of crypto_hash. Encrypted transmission is only supported for the
205 knet transport.
206 The default is none.
208 keyfile
211 This specifies the fully qualified path to the shared key used
212 to authenticate and encrypt data used within the Totem protocol.
213 The default is /etc/corosync/authkey.
215 key Shared key stored in configuration instead of authkey file. This
218 option has lower precedence than keyfile option so it's used
219 only when keyfile is not specified. Using this option is not
220 recommended for security reasons.
221 link_mode
224 This specifies the Kronosnet mode, which may be passive, active,
225 or rr (round-robin). passive: the active link with the lowest
226 priority will be used. If one or more links share the same pri‐
227 ority the one with the lowest link ID will be used. active: All
228 active links will be used simultaneously to send traffic. link
229 priority is ignored. rr: Round-Robin policy. Each packet will
230 be sent to the next active link in order.
231 If only one interface directive is specified, passive is auto‐
233 matically chosen.
234 The maximum number of interface directives that is allowed with
236 Kronosnet is 8. For other transports it is 1.
237 netmtu This specifies the network maximum transmit unit. To set this
240 value beyond 1500, the regular frame MTU, requires ethernet
241 devices that support large, or also called jumbo, frames. If
242 any device in the network doesn't support large frames, the pro‐
243 tocol will not operate properly. The hosts must also have their
244 mtu size set from 1500 to whatever frame size is specified here.
245 Please note while some NICs or switches claim large frame sup‐
247 port, they support 9000 MTU as the maximum frame size including
248 the IP header. Setting the netmtu and host MTUs to 9000 will
249 cause totem to use the full 9000 bytes of the frame. Then Linux
250 will add a 18 byte header moving the full frame size to 9018.
251 As a result some hardware will not operate properly with this
252 size of data. A netmtu of 8982 seems to work for the few large
253 frame devices that have been tested. Some manufacturers claim
254 large frame support when in fact they support frame sizes of
255 4500 bytes.
256 When sending multicast traffic, if the network frequently recon‐
258 figures, chances are that some device in the network doesn't
259 support large frames.
260 Choose hardware carefully if intending to use large frame sup‐
262 port.
263 The default is 1500.
265 transport
268 This directive controls the transport mechanism used. The
269 default is knet. The transport type can also be set to udpu or
270 udp. Only knet allows crypto or multiple interfaces per node.
271 cluster_name
274 This specifies the name of cluster and it's used for automatic
275 generating of multicast address.
276 config_version
279 This specifies version of config file. This is converted to
280 unsigned 64-bit int. By default it's 0. Option is used to pre‐
281 vent joining old nodes with not up-to-date configuration. If
282 value is not 0, and node is going for first time (only for first
283 time, join after split doesn't follow this rules) from single-
284 node membership to multiple nodes membership, other nodes con‐
285 fig_versions are collected. If current node config_version is
286 not equal to highest of collected versions, corosync is termi‐
287 nated.
288 ip_version
291 This specifies version of IP to ask DNS resolver for. The value
292 can be one of ipv4 (look only for an IPv4 address) , ipv6 (check
293 only IPv6 address) , ipv4-6 (look for all address families and
294 use first IPv4 address found in the list if there is such
295 address, otherwise use first IPv6 address) and ipv6-4 (look for
296 all address families and use first IPv6 address found in the
297 list if there is such address, otherwise use first IPv4
298 address).
299 Default (if unspecified) is ipv6-4 for knet and udpu transports
301 and ipv4 for udp.
302 Knet transport allows to have a both ipv4 and ipv6 address, pro‐
304 vided they are consistent on each link.
305 Within the totem directive, there are several configuration
307 options which are used to control the operation of the protocol.
308 It is generally not recommended to change any of these values
309 without proper guidance and sufficient testing. Some networks
310 may require larger values if suffering from frequent reconfigu‐
311 rations. Some applications may require faster failure detection
312 times which can be achieved by reducing the token timeout.
313 token This timeout is used directly or as a base for real token time‐
316 out calculation (explained in token_coefficient section). Token
317 timeout specifies in milliseconds until a token loss is declared
318 after not receiving a token. This is the time spent detecting a
319 failure of a processor in the current configuration. Reforming
320 a new configuration takes about 50 milliseconds in addition to
321 this timeout.
322 For real token timeout used by totem it's possible to read cmap
324 value of runtime.config.totem.token key.
325 The default is 1000 milliseconds.
327 token_warning
330 Specifies the interval between warnings that the token has not
331 been received. The value is a percentage of the token timeout
332 and can be set to 0 to disable warnings.
333 The default is 75%.
335 token_coefficient
338 This value is used only when nodelist section is specified and
339 contains at least 3 nodes. If so, real token timeout is then
340 computed as token + (number_of_nodes - 2) * token_coefficient.
341 This allows cluster to scale without manually changing token
342 timeout every time new node is added. This value can be set to 0
343 resulting in effective removal of this feature.
344 The default is 650 milliseconds.
346 token_retransmit
349 This timeout specifies in milliseconds after how long before
350 receiving a token the token is retransmitted. This will be
351 automatically calculated if token is modified. It is not recom‐
352 mended to alter this value without guidance from the corosync
353 community.
354 The default is 238 milliseconds.
356 knet_compression_model
359 The (optional) type of compression used by Kronosnet. The values
360 available depend on the build and also avaialable libraries.
361 Typically zlib and lz4 will be available but bzip2 and others
362 could also be allowed. The default is 'none'
363 knet_compression_threshold
366 Tells knet to NOT compress any packets that are smaller than the
367 value indicated. Default 100 bytes.
368 Set to 0 to reset to the default. Set to 1 to compress every‐
370 thing.
371 knet_compression_level
374 Many compression libraries allow tuning of compression parame‐
375 ters. For example 0 or 1 ... 9 are commonly used to determine
376 the level of compression. This value is passed unmodified to the
377 compression library so it is recommended to consult the
378 library's documentation for more detailed information.
379 hold This timeout specifies in milliseconds how long the token should
382 be held by the representative when the protocol is under low
383 utilization. It is not recommended to alter this value without
384 guidance from the corosync community.
385 The default is 180 milliseconds.
387 token_retransmits_before_loss_const
390 This value identifies how many token retransmits should be
391 attempted before forming a new configuration. If this value is
392 set, retransmit and hold will be automatically calculated from
393 retransmits_before_loss and token.
394 The default is 4 retransmissions.
396 join This timeout specifies in milliseconds how long to wait for join
399 messages in the membership protocol.
400 The default is 50 milliseconds.
402 send_join
405 This timeout specifies in milliseconds an upper range between 0
406 and send_join to wait before sending a join message. For con‐
407 figurations with less than 32 nodes, this parameter is not nec‐
408 essary. For larger rings, this parameter is necessary to ensure
409 the NIC is not overflowed with join messages on formation of a
410 new ring. A reasonable value for large rings (128 nodes) would
411 be 80msec. Other timer values must also change if this value is
412 changed. Seek advice from the corosync mailing list if trying
413 to run larger configurations.
414 The default is 0 milliseconds.
416 consensus
419 This timeout specifies in milliseconds how long to wait for con‐
420 sensus to be achieved before starting a new round of membership
421 configuration. The minimum value for consensus must be 1.2 *
422 token. This value will be automatically calculated at 1.2 *
423 token if the user doesn't specify a consensus value.
424 For two node clusters, a consensus larger than the join timeout
426 but less than token is safe. For three node or larger clusters,
427 consensus should be larger than token. There is an increasing
428 risk of odd membership changes, which still guarantee virtual
429 synchrony, as node count grows if consensus is less than token.
430 The default is 1200 milliseconds.
432 merge This timeout specifies in milliseconds how long to wait before
435 checking for a partition when no multicast traffic is being
436 sent. If multicast traffic is being sent, the merge detection
437 happens automatically as a function of the protocol.
438 The default is 200 milliseconds.
440 downcheck
443 This timeout specifies in milliseconds how long to wait before
444 checking that a network interface is back up after it has been
445 downed.
446 The default is 1000 milliseconds.
448 fail_recv_const
451 This constant specifies how many rotations of the token without
452 receiving any of the messages when messages should be received
453 may occur before a new configuration is formed.
454 The default is 2500 failures to receive a message.
456 seqno_unchanged_const
459 This constant specifies how many rotations of the token without
460 any multicast traffic should occur before the hold timer is
461 started.
462 The default is 30 rotations.
464 heartbeat_failures_allowed
467 [HeartBeating mechanism] Configures the optional HeartBeating
468 mechanism for faster failure detection. Keep in mind that engag‐
469 ing this mechanism in lossy networks could cause faulty loss
470 declaration as the mechanism relies on the network for heart‐
471 beating.
472 So as a rule of thumb use this mechanism if you require improved
474 failure in low to medium utilized networks.
475 This constant specifies the number of heartbeat failures the
477 system should tolerate before declaring heartbeat failure e.g 3.
478 Also if this value is not set or is 0 then the heartbeat mecha‐
479 nism is not engaged in the system and token rotation is the
480 method of failure detection
481 The default is 0 (disabled).
483 max_network_delay
486 [HeartBeating mechanism] This constant specifies in milliseconds
487 the approximate delay that your network takes to transport one
488 packet from one machine to another. This value is to be set by
489 system engineers and please don't change if not sure as this
490 effects the failure detection mechanism using heartbeat.
491 The default is 50 milliseconds.
493 window_size
496 This constant specifies the maximum number of messages that may
497 be sent on one token rotation. If all processors perform
498 equally well, this value could be large (300), which would
499 introduce higher latency from origination to delivery for very
500 large rings. To reduce latency in large rings(16+), the
501 defaults are a safe compromise. If 1 or more slow processor(s)
502 are present among fast processors, window_size should be no
503 larger than 256000 / netmtu to avoid overflow of the kernel
504 receive buffers. The user is notified of this by the display of
505 a retransmit list in the notification logs. There is no loss of
506 data, but performance is reduced when these errors occur.
507 The default is 50 messages.
509 max_messages
512 This constant specifies the maximum number of messages that may
513 be sent by one processor on receipt of the token. The max_mes‐
514 sages parameter is limited to 256000 / netmtu to prevent over‐
515 flow of the kernel transmit buffers.
516 The default is 17 messages.
518 miss_count_const
521 This constant defines the maximum number of times on receipt of
522 a token a message is checked for retransmission before a
523 retransmission occurs. This parameter is useful to modify for
524 switches that delay multicast packets compared to unicast pack‐
525 ets. The default setting works well for nearly all modern
526 switches.
527 The default is 5 messages.
529 knet_pmtud_interval
532 How often the knet PMTUd runs to look for network MTU changes.
533 Value in seconds, default: 30
534 Within the logging directive, there are several configuration options
537 which are all optional.
538 The following 3 options are valid only for the top level logging direc‐
541 tive:
542 timestamp
545 This specifies that a timestamp is placed on all log messages.
546 It can be one of off (no timestamp), on (second precision time‐
547 stamp) or hires (millisecond precision timestamp - only when
548 supported by LibQB).
549 The default is hires (or on if hires is not supported).
551 fileline
554 This specifies that file and line should be printed.
555 The default is off.
557 function_name
560 This specifies that the code function name should be printed.
561 The default is off.
563 blackbox
566 This specifies that blackbox functionality should be enabled.
567 The default is on.
569 The following options are valid both for top level logging directive
572 and they can be overridden in logger_subsys entries.
573 to_stderr
576 to_logfile
578 to_syslog
580 These specify the destination of logging output. Any combination
581 of these options may be specified. Valid options are yes and no.
582 The default is syslog and stderr.
584 Please note, if you are using to_logfile and want to rotate the
586 file, use logrotate(8) with the option copytruncate. eg.
587 /var/log/corosync.log {
588 missingok
589 compress
590 notifempty
591 daily
592 rotate 7
593 copytruncate
594 }
595 logfile
598 If the to_logfile directive is set to yes , this option speci‐
599 fies the pathname of the log file.
600 No default.
602 logfile_priority
605 This specifies the logfile priority for this particular subsys‐
606 tem. Ignored if debug is on. Possible values are: alert, crit,
607 debug (same as debug = on), emerg, err, info, notice, warning.
608 The default is: info.
610 syslog_facility
613 This specifies the syslog facility type that will be used for
614 any messages sent to syslog. options are daemon, local0, local1,
615 local2, local3, local4, local5, local6 & local7.
616 The default is daemon.
618 syslog_priority
621 This specifies the syslog level for this particular subsystem.
622 Ignored if debug is on. Possible values are: alert, crit, debug
623 (same as debug = on), emerg, err, info, notice, warning.
624 The default is: info.
626 debug This specifies whether debug output is logged for this particu‐
629 lar logger. Also can contain value trace, what is highest level
630 of debug information.
631 The default is off.
633 Within the logging directive, logger_subsys directives are optional.
636 Within the logger_subsys sub-directive, all of the above logging con‐
639 figuration options are valid and can be used to override the default
640 settings. The subsys entry, described below, is mandatory to identify
641 the subsystem.
642 subsys This specifies the subsystem identity (name) for which logging
645 is specified. This is the name used by a service in the
646 log_init() call. E.g. 'CPG'. This directive is required.
647 Within the quorum directive it is possible to specify the quorum algo‐
650 rithm to use with the
651 provider
654 directive. At the time of writing only corosync_votequorum is
655 supported. See votequorum(5) for configuration options.
656 Within the nodelist directive it is possible to specify specific infor‐
659 mation about nodes in cluster. Directive can contain only node sub-
660 directive, which specifies every node that should be a member of the
661 membership, and where non-default options are needed. Every node must
662 have at least ring0_addr field filled.
663 Every node that should be a member of the membership must be specified.
665 Possible options are:
667 ringX_addr
669 This specifies IP or network hostname address of the particular
670 node. X is a link number.
671 nodeid This configuration option is required for each node for Kronos‐
674 net mode. It is a 32 bit value specifying the node identifier
675 delivered to the cluster membership service. The node identifier
676 value of zero is reserved and should not be used. If knet is
677 set, this field must be set.
678 name This option is used mainly with knet transport to identify local
681 node. It's also used by client software (pacemaker). Algorithm
682 for identifying local node is following:
683 1. Looks up $HOSTNAME in the nodelist
685 2. If this fails strip the domain name from $HOSTNAME and
687 looks up that in the nodelist
688 3. If this fails look in the nodelist for a fully-qualified
690 name whose short version matches the short version of
691 $HOSTNAME
692 4. If all this fails then search the interfaces list for an
694 address that matches a name in the nodelist
695 Within the system directive it is possible to specify system options.
698 Possible options are:
700 qb_ipc_type
702 This specifies type of IPC to use. Can be one of native
703 (default), shm and socket. Native means one of shm or socket,
704 depending on what is supported by OS. On systems with support
705 for both, SHM is selected. SHM is generally faster, but need to
706 allocate ring buffer file in /dev/shm.
707 sched_rr
710 Should be set to yes (default) if corosync should try to set
711 round robin realtime scheduling with maximal priority to itself.
712 When setting of scheduler fails, fallback to set maximal prior‐
713 ity.
714 priority
717 Set priority of corosync process. Valid only when sched_rr is
718 set to no. Can be ether numeric value with similar meaning as
719 nice(1) or max / min meaning maximal / minimal priority (so min‐
720 imal / maximal nice value).
721 move_to_root_cgroup
724 Should be set to yes (default) if corosync should try to move
725 itself to root cgroup. This feature is available only for sys‐
726 tems with cgroups with RT sched enabled (Linux with CON‐
727 FIG_RT_GROUP_SCHED kernel option).
728 state_dir
731 Existing directory where corosync should chdir into. Corosync
732 stores important state files and blackboxes there.
733 The default is /var/lib/corosync.
735 Within the resources directive it is possible to specify options for
738 resources.
739 Possible option is:
741 watchdog_device
743 (Valid only if Corosync was compiled with watchdog support.)
744 Watchdog device to use, for example /dev/watchdog. If unset,
745 empty or "off", no watchdog is used.
746 In a cluster with properly configured power fencing a watchdog
748 provides no additional value. On the other hand, slow watchdog
749 communication may incur multi-second delays in the Corosync main
750 loop, potentially breaking down membership. IPMI watchdogs are
751 particularly notorious in this regard: read about kip‐
752 mid_max_busy_us in IPMI.txt in the Linux kernel documentation.
753
756 For example to add a node with address 10.24.38.108 with nodeid 3. The
757 node has the name NEW (in DNS or /etc/hosts) and is not currently run‐
758 ning corosync. The current corosync.conf nodelist looks like this:
759 nodelist {
761 node {
762 nodeid: 1
763 ring0_addr: 10.24.38.101
764 name: node1
765 }
766 node {
767 nodeid: 2
768 ring0_addr: 10.24.38.102
769 name: node2
770 }
772 }
773 Add a new entry for the node below the existing nodes. Node entries
775 don't have to be in nodeid order, but it will help keep you sane. So
776 the nodelist now looks like this:
777 nodelist {
779 node {
780 nodeid: 1
781 ring0_addr: 10.24.38.101
782 name: node1
783 }
784 node {
785 nodeid: 2
786 ring0_addr: 10.24.38.102
787 name: node2
788 }
790 node {
791 nodeid: 3
792 ring0_addr: 10.24.38.108
793 name: NEW
794 }
796 }
797 This file must then be copied onto all three nodes - the existing two
799 nodes, and the new one. On one of the existing corosync nodes, tell
800 corosync to re-read the updated config file into memory:
801 corosync-cfgtool -R
803 This command only needs to be run on one node in the cluster. You may
805 then start corosync on the NEW node and it should join the cluster. If
806 this doesn't work as expected then check the communications between all
807 three nodes is working, and check the syslog files on all nodes for
808 more information. It's important to note that the key bit of informa‐
809 tion about a node failing to join might be on a different node than you
810 expect.
811
814 This is the reverse procedure to 'Adding a node' above. First you need
815 to shut down the node you will be removing from the cluster.
816 corosync-cfgtool -H
818 Then delete the nodelist stanza from corosync.conf and finally update
822 corosync on the remaining nodes by running
823 corosync-cfgtool -R
825 on one of them.
827
830 corosync resolves ringX_addr names/IP addresses using the getad‐
831 drinfo(3) call with respect of totem.ip_version setting.
832 getaddrinfo() function uses a sophisticated algorithm to sort node
834 addresses into a preferred order and corosync always chooses the first
835 address in that list of the required family. As such it is essential
836 that your DNS or /etc/hosts files are correctly configured so that all
837 addresses for ringX appear on the same network (or are reachable with
838 minimal hops) and over the same IP protocol. If this is not the case
839 then some nodes might not be able to join the cluster. It is possible
840 to override the search order used by getaddrinfo() using the configura‐
841 tion file /etc/gai.conf(5) if necessary, but this is not recommended.
842 If there is any doubt about the order of addresses returned from getad‐
844 drinfo() then it might be simpler to use IP addresses (v4 or v6) in the
845 ringX_addr field.
846
849 /etc/corosync/corosync.conf
850 The corosync executive configuration file.
851
854 corosync_overview(7), votequorum(5), corosync-qdevice(8), logrotate(8)
855 getaddrinfo(3) gai.conf(5)
856corosync Man Page 2019-01-10 COROSYNC_CONF(5)