Some platforms requires aligned memory access. For such platforms,
special code was added using address modulo 4 to check if aligning is
needed or not. This may be problem for 64 bits platforms. Also check in
app_deliver_fn was incorrect and always true.

Solution is to use modulo sizeof pointer and add parentheses to fix the
check in app_deliver_fn function.

Signed-off-by: Jan Friesse <jfriesse@redhat.com>
Reviewed-by: Christine Caulfield <ccaulfie@redhat.com>

Useful for external code to easily tell where corosync.conf
is (in case someone configured it for /usr/local/etc, ...)

E.g. pacemaker's crm_report collects corosync.conf, and some
of its testing tools generate a corosync.conf for a test cluster.

Signed-off-by: Jan Friesse <jfriesse@redhat.com>
Reviewed-by: Fabio M. Di Nitto <fdinitto@redhat.com>

This was the real problem behind 384d168b: Debian experimental now
sports a dash with LINENO support, so configure does not fall back to
using bash instead, choking on such bash-only constructs.  Unfortunately
this didn't bail out cleanly, just unexpectedly set link_all_deplibs to
no, and the error message

./configure: 13158: test: yes: unexpected operator

stayed unnoticed in the logs.  Actually, link_all_deplibs=no is the
default in Debian, reducing overlinking and causing confusion overall,
see https://debbugs.gnu.org/db/13/13920.html

 for example.

I think being explicit about used interfaces has its merit, so now that
Corosync has it, it might be advantageous to disable link_all_deplibs
by default across the board (after this patch re-enables it as a side
effect).

Signed-off-by: Ferenc Wágner <wferi@debian.org>
Reviewed-by: Jan Friesse <jfriesse@redhat.com>

Commit to drop packets from unlisted IPs made ifdown case not working
because msg_name is unset for socketpair.

solution is to drop packets from unlisted IPs only when bind state is
BIND_STATE_REGULAR.

Signed-off-by: Jan Friesse <jfriesse@redhat.com>
Reviewed-by: Christine Caulfield <ccaulfie@redhat.com>

Don't rely on implicit symbol finding (cs_strerror being most prominent
example) but rather use explicit one.

This makes current debian experimental happy (compile source)

Signed-off-by: Jan Friesse <jfriesse@redhat.com>
Reviewed-by: Fabio M. Di Nitto <fdinitto@redhat.com>

Commit 92e0f9c7 added switching of
totempg buffers in sync phase. But because buffers got switch too early
there was a problem when delivering recovered messages (messages got
corrupted and/or lost). Solution is to switch buffers after recovered
messages got delivered.

I think it is worth to describe complete history with reproducers so it
doesn't get lost.

It all started with 40263892 (more info
about original problem is described in
https://bugzilla.redhat.com/show_bug.cgi?id=820821). This patch
solves problem which is way to be reproduced with following reproducer:
- 2 nodes
- Both nodes running corosync and testcpg
- Pause node 1 (SIGSTOP of corosync)
- On node 1, send some messages by testcpg
  (it's not answering but this doesn't matter). Simply hit ENTER key
  few times is enough)
- Wait till node 2 detects that node 1 left
- Unpause node 1 (SIGCONT of corosync)

and on node 1 newly mcasted cpg messages got sent before sync barrier,
so node 2 logs "Unknown node -> we will not deliver message".

Solution was to add switch of totemsrp new messages buffer.

This patch was not enough so new one
(92e0f9c7) was created. Reproducer of
problem was similar, just cpgverify was used instead of testcpg.
Occasionally when node 1 was unpaused it hang in sync phase because
there was a partial message in totempg buffers. New sync message had
different frag cont so it was thrown away and never delivered.

After many years problem was found which is solved by this patch
(original issue describe in
https://github.com/corosync/corosync/issues/660

).
Reproducer is more complex:
- 2 nodes
- Node 1 is rate-limited (used script on the hypervisor side):
  ```
  iface=tapXXXX
  # ~0.1MB/s in bit/s
  rate=838856
  # 1mb/s
  burst=1048576
  tc qdisc add dev $iface root handle 1: htb default 1
  tc class add dev $iface parent 1: classid 1:1 htb rate ${rate}bps \
    burst ${burst}b
  tc qdisc add dev $iface handle ffff: ingress
  tc filter add dev $iface parent ffff: prio 50 basic police rate \
    ${rate}bps burst ${burst}b mtu 64kb "drop"
  ```
- Node 2 is running corosync and cpgverify
- Node 1 keeps restarting of corosync and running cpgverify in cycle
  - Console 1: while true; do corosync; sleep 20; \
      kill $(pidof corosync); sleep 20; done
  - Console 2: while true; do ./cpgverify;done

And from time to time (reproduced usually in less than 5 minutes)
cpgverify reports corrupted message.

Signed-off-by: Jan Friesse <jfriesse@redhat.com>
Reviewed-by: Fabio M. Di Nitto <fdinitto@redhat.com>

Signed-off-by: Christine Caulfield <ccaulfie@redhat.com>
Reviewed-by: Jan Friesse <jfriesse@redhat.com>

The consensus timeout is 1.2 * token_timeout,
which has been changeg from 1000 to 3000, so change also consensus
timeout.

Signed-off-by: miharahiro <hmihara@redhat.com>
Reviewed-by: Christine Caulfield <ccaulfie@redhat.com>
Reviewed-by: Jan Friesse <jfriesse@redhat.com>

Thanks Ryan Cai <ycaibb@gmail.com> for reporting the problem.

Signed-off-by: Jan Friesse <jfriesse@redhat.com>
Reviewed-by: Christine Caulfield <ccaulfie@redhat.com>

Previously, existence of retransmit messages canceled holding
of token (and never allowed representative to enter token hold
state).

This makes token rotating maximum speed and keeps processor
resending messages over and over again - overloading network
and reducing chance to successfully deliver the messages.

Also there were reports of various Antivirus / IPS / IDS which slows
down delivery of packets with certain sizes (packets bigger than token)
what make Corosync retransmit messages over and over again.

Proposed solution is to allow representative to enter token hold
state when there are only retransmit messages. This allows network to
handle overload and/or gives Antivirus/IPS/IDS enough time scan and
deliver packets without corosync entering "FAILED TO RECEIVE" state and
adding more load to network.

Signed-off-by: Jan Friesse <jfriesse@redhat.com>
Reviewed-by: Christine Caulfield <ccaulfie@redhat.com>

Knet limits maximum node id to 16-bit type. This was not ensured in
corosync and it was possible to set nodeid to value >= 65536 and
(surprisingly) most of the things were working quite well because of
overflow. corosync-cmapctl -m stats contained knet nodeid in
stats.knet. subtree, so for nodeid 65536 result was:

Can't get value of stats.knet.node0.link0.connected. Error
CS_ERR_NOT_EXIST

Commit implements checking of nodeid and limits it to KNET_MAX_HOST
value when knet is used.

Signed-off-by: Jan Friesse <jfriesse@redhat.com>
Reviewed-by: Christine Caulfield <ccaulfie@redhat.com>

Nodeid is required for knet for every node. Right now, existence of
nodeid is checked only for local for local node, so broaden the test.

Signed-off-by: Jan Friesse <jfriesse@redhat.com>
Reviewed-by: Christine Caulfield <ccaulfie@redhat.com>

Signed-off-by: Jan Friesse <jfriesse@redhat.com>
Reviewed-by: Christine Caulfield <ccaulfie@redhat.com>

Show 'n' also for first localhost link, so all localhost links
are marked consistently with non-brief display.

Signed-off-by: Jan Friesse <jfriesse@redhat.com>
Reviewed-by: Christine Caulfield <ccaulfie@redhat.com>

Needed for having correct index of localhost

Signed-off-by: Jan Friesse <jfriesse@redhat.com>
Reviewed-by: Christine Caulfield <ccaulfie@redhat.com>

Signed-off-by: Jan Friesse <jfriesse@redhat.com>
Reviewed-by: Christine Caulfield <ccaulfie@redhat.com>

Signed-off-by: Jan Friesse <jfriesse@redhat.com>
Reviewed-by: Christine Caulfield <ccaulfie@redhat.com>

totem.nodeid is relict from times when nodelist was not required and
totemsrp was sending whole membership with ip addresses.

With Corosync 3 ip addresses are no longer sent so
it is not possible to find "next" node ip address where to send token
(because only nodeid is sent) without having information about all of
the nodes stored locally.

When totem.nodeid was configured it was partly used and other parts
(most notably totemudpu_token_target_set) were using autogenerated
nodeid. Together it was not possible to create even single node
membership.

Solution is to ignore totem.nodeid completely (and display warning when
it is set).

Signed-off-by: Jan Friesse <jfriesse@redhat.com>
Reviewed-by: Christine Caulfield <ccaulfie@redhat.com>

Currently if there is a gap in the links (eg link0 is missing)
corosync-cfgtool -s will still display the links as 0,1,2,3...
even if they are 1,2,5,6...

Also display the KNET transport type with the link in
corosync-cfgtool -s & -n

Signed-off-by: Christine Caulfield <ccaulfie@redhat.com>
Reviewed-by: Jan Friesse <jfriesse@redhat.com>

Support for cgroup v2 is very similar to cgroup v1 just checking (and
writing) different file.

Because of all the problems described later with cgroup v2 new "auto"
mode (new default) is added. This mode first tries to set rr scheduling
and moves Corosync to root cgroup only if it fails.

Testing this feature is a bit harder than with cgroup v1 so it's
probably worh noting in this commit message.

1. Copy some service file (I've used httpd service) and set
   CPUQuota=30% in the [service] section.
2. Check /sys/fs/cgroup/cgroup.subtree_control - there should be no
   "cpu"
3. Start modified service
4. Check /sys/fs/cgroup/cgroup.subtree_control - there should be "cpu"
5. Start corosync - It should be able to get rt priority

When move_to_root_cgroup is disabled (applies only for kernels
with CONFIG_RT_GROUP_SCHED enabled), behavior differs:
- If corosync is started before modified service, so
  there is no "cpu" in /sys/fs/cgroup/cgroup.subtree_control
  corosync starts without problem and gets rt priority.
  Starting modified service later will never add "cpu" into
  /sys/fs/cgroup/cgroup.subtree_control (because corosync is holding
  rt priority and it is placed in the non-root cgroup by systemd).

- When corosync is started after modified service, so "cpu"
  is in /sys/fs/cgroup/cgroup.subtree_control, corosync is not
  able to get RT priority.

It's worth noting problems when cgroup v2 is used together with systemd
logging described in corosync.conf(5) man page.

Signed-off-by: Jan Friesse <jfriesse@redhat.com>
Reviewed-by: Christine Caulfield <ccaulfie@redhat.com>

The libqb map API leaves 'ownership' of the data with the caller
but does its own lifetime management, so it can easily happen that
map_rm() is called and the data deleted by the caller.
But if an iterator is running over that item then the map entry
will not get removed (leaving dangling pointers) until later.

libqb has a hack-y callback that tells the owner when it is safe to
delete the allocated memory, so we hook into that. icmap is already
using this.

Signed-off-by: Christine Caulfield <ccaulfie@redhat.com>
Reviewed-by: Jan Friesse <jfriesse@redhat.com>

Internally knet is using just one link for localhost so for single node
configuration knet_link_get_link_list returns only one entry. This is
propagated to `corosync-cfgtool -s`.

Signed-off-by: Jan Friesse <jfriesse@redhat.com>
Reviewed-by: Christine Caulfield <ccaulfie@redhat.com>

This reverts commit 57e6b86b

.

We are in process of finding better solution so reverting for now.

Signed-off-by: Jan Friesse <jfriesse@redhat.com>

This reverts commit 9d3df569

.

We are in process of finding better solution so reverting for now.

Signed-off-by: Jan Friesse <jfriesse@redhat.com>

Signed-off-by: Jan Friesse <jfriesse@redhat.com>
Reviewed-by: Christine Caulfield <ccaulfie@redhat.com>

corosync_cfg_trackstop expects reply but that was never sent. Make sure
to send reply so corosync_cfg_trackstop works.

Signed-off-by: Jan Friesse <jfriesse@redhat.com>
Reviewed-by: Christine Caulfield <ccaulfie@redhat.com>

Support for cgroup v2 is very similar to cgroup v1 just checking (and
writing) different file.

Testing this feature is a bit harder than with cgroup v1 so it's
probably worh noting in this commit message.

1. Copy some service file (I've used httpd service) and set
   CPUQuota=30% in the [service] section.
2. Check /sys/fs/cgroup/cgroup.subtree_control - there should be no
   "cpu"
3. Start modified service
4. Check /sys/fs/cgroup/cgroup.subtree_control - there should be "cpu"
5. Start corosync - It should be able to get rt priority

When move_to_root_cgroup is disabled, behavior differs:
- If corosync is started before modified service, so
  there is no "cpu" in /sys/fs/cgroup/cgroup.subtree_control
  corosync starts without problem and gets rt priority.
  Starting modified service later will never add "cpu" into
  /sys/fs/cgroup/cgroup.subtree_control (because corosync is holding
  rt priority and it is placed in the non-root cgroup by systemd).

- When corosync is started after modified service, so "cpu"
  is in /sys/fs/cgroup/cgroup.subtree_control, corosync is not
  able to get RT priority.

Signed-off-by: Jan Friesse <jfriesse@redhat.com>
Reviewed-by: Christine Caulfield <ccaulfie@redhat.com>

... to be in align with crypto_cypher and crypto_hash.

Reload (corosync-cfgtool -R) works without any problem and changing of
key is not supported anyway,

Signed-off-by: Jan Friesse <jfriesse@redhat.com>
Reviewed-by: Christine Caulfield <ccaulfie@redhat.com>

Signed-off-by: Jan Friesse <jfriesse@redhat.com>
Reviewed-by: Christine Caulfield <ccaulfie@redhat.com>

Use knet_get_crypto_list to find knet supported crypto models and use
them instead of hardcoded list.

Also fix compression handling. Previously knet_compression_model
value was not checked at all and was directly passed to knet.

Use knet_get_compress_list to find knet supported compress models and
use them to check validity of config file and for more informative
error message.

Lastly enhance corosync version display with information
about available crypto/compression models.

Signed-off-by: Jan Friesse <jfriesse@redhat.com>
Reviewed-by: Christine Caulfield <ccaulfie@redhat.com>

Apostrophe as the first character of the input line indicates a
request, so groff complained: macro 'onwire'' not defined.

Signed-off-by: Ferenc Wágner <wferi@debian.org>
Reviewed-by: Jan Friesse <jfriesse@redhat.com>

totemknet_configure_compression was using knet_context
just to gather the knet handle / instance.

On first time config knet_contex is not initialized till
much later in the code, passing some random garbage pointers
to knet_handle_compress, that would crash later trying
to acquire a mutex lock.

Signed-off-by: Fabio M. Di Nitto <fdinitto@redhat.com>
Reviewed-by: Jan Friesse <jfriesse@redhat.com>

Fix integer underflow when computing `namelen` in `nodelist_byname`,
always use computed `namelen`.
Fixes #626.

Signed-off-by: Johannes Krupp <johannes.krupp@cispa.saarland>
Reviewed-by: Jan Friesse <jfriesse@redhat.com>

Insted of using "magic number" use UDP_NETMTU constant.

Signed-off-by: liangxin1300 <XLiang@suse.com>
Reviewed-by: Jan Friesse <jfriesse@redhat.com>

Retry knet_handle_new without privileged operations if it fails

knet_handle_new can fail with ENAMETOOLONG if its privileged operations
fail, which can happen if we're running as a user process or in an
unprivileged container.

This adds a cmap key 'allow_knet_handle_fallback' that defaults to no,
which is the current behavior of exiting with error if the knet_handle
can't be created with privileged operations. If the new cmap key is set
to 'yes' and the knet_handle creation fails, fallback to creating the
handle using unprivileged operations is tried.

Signed-off-by: Dan Streetman <ddstreet@canonical.com>
Reviewed-by: Jan Friesse <jfriesse@redhat.com>

Don't lock all current and future memory if can't
increase memlock rlimit.

If we fail to increase our RLIMIT_MEMLOCK, then locking all our current
and future memory is extremely dangerous; once our memory use reaches
our RLIMIT_MEMLOCK, memory allocations will start failing, very likely
leading to our entire process crashing.

This can happen if we aren't a privileged process, for example if
running as non-root user, or inside an unprivileged container.

Signed-off-by: Dan Streetman <ddstreet@canonical.com>
Reviewed-by: Jan Friesse <jfriesse@redhat.com>

Signed-off-by: Fabio M. Di Nitto <fdinitto@redhat.com>
Reviewed-by: Jan Friesse <jfriesse@redhat.com>

Move exec_prefix sanitize closer to prefix. This is not
functional change, just group functional tests together.

Signed-off-by: Fabio M. Di Nitto <fdinitto@redhat.com>
Reviewed-by: Jan Friesse <jfriesse@redhat.com>

prefix is sanitized already at the top of configure.ac to /usr,
hence the second instance can never hit.

Signed-off-by: Fabio M. Di Nitto <fdinitto@redhat.com>
Reviewed-by: Jan Friesse <jfriesse@redhat.com>

this also allows to use PKG_CONFIG_* macros immediately
in conditional calls

Signed-off-by: Fabio M. Di Nitto <fdinitto@redhat.com>
Reviewed-by: Jan Friesse <jfriesse@redhat.com>