Bug#947936: chrony: Does (still) not start properly on boot on buster

[Santiago Vila]

On Fri, Jan 03, 2020 at 11:21:42PM +0100, Vincent Blut wrote:

> > Unfortunately, AFAIK, conflicts are bi-directional, so apparently the
> > problem will persist in buster as far as chrony still has conflicts
> > in the systemd unit file.
> 
> What do you mean by “conflicts are bi-directional”?

I meant that it is enough that service "A" declares a conflict with service "B"
so that both of them conflict with the other, i.e. they have
the "symmetric property" even if the conflicts is only declared once.

At least that's how I interpret the words "vice versa" here:

Conflicts=

    A space-separated list of unit names. Configures negative
requirement dependencies. If a unit has a Conflicts= setting on
another unit, starting the former will stop the latter and vice versa.

So: If we tried to solve this in buster by dropping the use of
conflicts, and chrony still uses conflicts, maybe that would explain
that the problem is still there.

> Also, conflicting with systemd-timesyncd doesn’t seem to cause any issue on
> most systems (well, I hope ;-), so we should be cautious about incriminating
> “Conflicts= systemd-timesyncd.service” use as the root cause.

You are right. We should be cautious.

I really don't know which is the root cause, but I can reproduce this
failure in as many GCE machines as desired via cloning.

So I have just created two different machines for you and Michael to
see this by yourself (please check your private email for access details).

My suspicious is that this is some sort of race condition, but
I am not expert enough on systemd stuff to debug it.

Thanks.