[ClusterLabs] Possible timing bug in SLES15

[Ulrich Windl]

Hi!

I just examined the corosync.service unit in SLES15. It contains:
# /usr/lib/systemd/system/corosync.service
[Unit]
Description=Corosync Cluster Engine
Documentation=man:corosync man:corosync.conf man:corosync_overview
ConditionKernelCommandLine=!nocluster
Requires=network-online.target
After=network-online.target
...

However the documentation says corosync requires synchronized system clocks.
With this configuration corosync starts before the clocks are synchronized:

Oct 05 14:57:47 h16 ntpd[6767]: ntpd 4.2.8p15 at 1.3728-o Tue Jun 15 12:00:00 UTC 2021 (1): Starting
...
Oct 05 14:57:48 h16 systemd[1]: Starting Wait for ntpd to synchronize system clock...
...
Oct 05 14:57:48 h16 corosync[6793]:   [TOTEM ] Initializing transport (UDP/IP Unicast).
...
Oct 05 14:57:48 h16 systemd[1]: Started Corosync Cluster Engine.
...
Oct 05 14:58:10 h16 systemd[1]: Started Wait for ntpd to synchronize system clock.
Oct 05 14:58:10 h16 systemd[1]: Reached target System Time Synchronized.

Only pacemaker.service has:
# /usr/lib/systemd/system/pacemaker.service
[Unit]
Description=Pacemaker High Availability Cluster Manager
Documentation=man:pacemakerd
Documentation=https://clusterlabs.org/pacemaker/doc/en-US/Pacemaker/2.0/html-single/Pacemaker_Explained/index.html 

# DefaultDependencies takes care of sysinit.target,
# basic.target, and shutdown.target

# We need networking to bind to a network address. It is recommended not to
# use Wants or Requires with network.target, and not to use
# network-online.target for server daemons.
After=network.target

# Time syncs can make the clock jump backward, which messes with logging
# and failure timestamps, so wait until it's done.
After=time-sync.target
...

Oct 05 14:58:10 h16 pacemakerd[6974]:  notice: Starting Pacemaker 2.0.4+20200616.2deceaa3a-3.9.1
But still it does not "Require" time-sync.target...

Doesn't corosync need synchronized clocks?

Regards,
Ulrich