On level 11 corosync.service is started by the dh_installinit snippet in
the postinst script, before the dh_installsystemd snippet could enable
it.  This leads to an immediate stop since version 3.0.1, where
corosync.service got the StopWhenUnneeded=true directive upstream.

Closes: #921265

Upstream version 3.0.1

It shall be a rule of thumb not to combine "application stack"
components run under particular init/supervision mechanism and
run by whatever other means (without transitive relationships
like when corosync's client runs from other pacemaker that is
itself started through systemd) when there's a directed graph
of reliance between them (sans constrained corner cases like
when of such components is a kernel module).

And corosync on its own is just a service provider that only
appears useful when utilized as a basic building block for
application specific distributed environments.

Therefore, we may assume whenever corosync gets started by the
means of systemd, it's because of a mechanized attempt to satisfy
declared dependency of some such corosync's client that is about
to be started under the service manager realms (directly or, by
induction, through the same triggering mechanism indirectly).
Hence, when there's no such client around anymore (unless
this dependant is being restarted at the moment, see below)
corosync shall rather shutdown as well.

In the past, there was an issue with systemd regarding said
inflicted restart of the dependant/client, but that's resolved
as of v236:
https://github.com/systemd/systemd/commit/


deb4e7080db9dcd2a1d51ccf7c357f88ea863e54

Signed-off-by: Jan Pokorný <jpokorny@redhat.com>
Reviewed-by: Jan Friesse <jfriesse@redhat.com>

AF_UNSPEC returns different results than AF_INET/AF_INET6, because of
nsswitch.conf search is in order and it stops asking other
modules once current module success.

Example of difference between previous and new code when ipv6-4 is used:
- /etc/hosts contains test_name with an ipv4
- previous code called AF_INET6 where /etc/hosts failed so other methods
were used which may return IPv6 addr -> result was ether fail or IPv6
address.
- new code calls AF_UNSPEC returning IPv4 defined in /etc/hosts ->
result is IPv4 address

New code behavior should solve problems caused by nss-myhostname.

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

more changes are to be expected on this front as the API evolves in
knet master.

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

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

Here we're very far from entering the main loop, even farther from
sending the READY notification to systemd.  This sounded awkward:

systemd[1]: Starting Corosync Cluster Engine...
corosync[827]:   [MAIN  ] Corosync Cluster Engine ('2.99.5'):
  started and ready to provide service.
corosync[827]:   [MAIN  ] Corosync built-in features: dbus monitoring
  watchdog augeas systemd xmlconf snmp pie relro bindnow
corosync[827]:   [MAIN  ] parse error in config: No interfaces defined
corosync[827]:   [MAIN  ] Corosync Cluster Engine exiting with status 8
  at main.c:1378.
systemd[1]: corosync.service: Main process exited, code=exited,
  status=8/n/a
systemd[1]: corosync.service: Failed with result 'exit-code'.
systemd[1]: Failed to start Corosync Cluster Engine.

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

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

Upstream version 3.0.0

Nodelist is required now, and it's better to let the token timeout scale
with the cluster size.  All in all, we might as well patch the upstream
example into a working configuration.

It's given in unstable, we try to protect backports here.

From https://lists.clusterlabs.org/pipermail/users/2017-December/014262.html:

So now, not only the full function of logging was restored, but libqb
adapts to the changed behaviour of binutils 2.29+ linker also with
defensive (in part opt-in only, see below) measures providing
diagnostics in cases at least one such participating binary part
was linked with this new v1.0.3 libqb version:

* libqb v1.0.3 (linked using arbitrary ld/binutils version)
  that is run-time used by any other logging binary linked
  against libqb < v1.0.3 using ld/binutils 2.29+
  - libqb will issue a warning/notice to syslog about the
    probable issue on the side of the logging binary

* libqb < v1.0.3 linked using ld/binutils 2.29+ that is run-time
  used by any other logging binary linked against libqb v1.0.3+
  (valid as public-facing binary compatibility remains preserved)
  will make said binary terminate early on with an explanatory
  assertion message, showing what precondition does not hold, but only
  _under the condition this binary makes a use of QB_LOG_INIT_DATA_
  macro

Closes: #898266

Gbp-Dch: Short

Andreas Henriksson authored Dec 13, 2018 and Ferenc Wágner committed Dec 22, 2018

Otherwise it's detected differently on merged-usr vs non-merged.

Closes: #915224

system.run_dir was a little bit unfortunate and confusing name. Rename
to state_dir makes more evident what is content of this directory. To
keep setting consistent with code, get_run_dir is changed to
get_state_dir.

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

Originally totem.ip_version was used to force ip version used by totem.
With Knet this variable didn't make too much sense so it was not used.

Sadly rely only on DNS resolver order doesn't always work (RFC is quite
complicated, but if IPv6 is not configured then IPv4 is preferred), what
we tried to solve by forcing IPv6 and only if that fails, use IPv4.

Sadly this collides with nss_myhostname which is able to return every
local address and today system usually have at least one autogenerated
link-local IPv6 address so it is able to "overwrite" /etc/hosts.

Solution is to enhance totem.ip_version and use it also for Knet.
totem.ip_version is now just a flag for resolver and can have four
states: ipv4 (only IPv4 is used), ipv6 (only IPv6 is used), ipv4-6 (ask
IPv4 first and if it fails ask for IPv6) and ipv6-4 (ask IPv6 first and
if it fails ask for IPv4). Default for Knet and UDPU transports is
ipv6-4, for UDP it's ipv4, because autogenerated mcast addr doesn't play
too well with ipv6-4.

So everywhere where nss_myhostname becomes problem, it's just possible
to set totem.ip_version to ipv4-6.

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

It's required to create TOTEM logsys subsys before totemip_parse is used
(so before totem_config_read). Logsys is not yet fully initialized, but
it's good enough.

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>