[prev in list] [next in list] [prev in thread] [next in thread] 

List:       systemd-devel
Subject:    Re: [systemd-devel] alternative approach to waiting for system time to be set
From:       Lennart Poettering <lennart () poettering ! net>
Date:       2018-03-20 15:19:14
Message-ID: 20180320151914.GA29229 () gardel-login
[Download RAW message or body]

On Di, 20.03.18 08:54, Peter A. Bigot (pab@pabigot.com) wrote:

> On 03/20/2018 12:57 AM, Peter A. Bigot wrote:
> > On 03/19/2018 04:17 PM, Lennart Poettering wrote:
> > > Would be great if you could rework it accordingly and submit it as PR.
> > 
> > https://github.com/systemd/systemd/pull/8494
> > 
> 
> I've addressed most of the review comments but before pushing a new version
> want to make a change that this proposes very visible, as it affects naming
> and documentation which is tedious to change multiple times.
> 
> In this PR, time-sync.target is no longer a Wants= dependency of
> systemd-timesyncd.  The rationale is that simply starting timesyncd does not
> satisfy the expectations for this synchronization point: setting the clock
> to what the local time was on last shutdown is problematic, as noted in
> issue #5097, and also seems to violate the spirit of LSB $timer which
> implies a After=time-sync.target.
> 
> Instead that dependency is moved to the new service, which blocks until the
> kernel has noted that the time is synchronized (not merely set).

I am pretty sure that both units should pull in time-sync.target, and
order themselves before it. Note that systemd-timesyncd.service will
will do something useful too when started, as it will ensure clock
monotinicity, as it saves/restores a timestamp file in /var.

The way I see it people have two options here: rely on the weaker time
syncronization rule that timesyncd itself provides or the strong one
that your new service introduces — at the cost of depending on an
external time source. If people enable the new service they get the
latter, if they don't they should still get the former. Hence both
should order themselves time-sync.target, and pull it in. And only if
all of the two that are enabled finish any other unit depending on it
should run.

This is somewhat similar to network-online.target logic, where it's
also up to the user ultimately with what kind of "online" meaning they
want to fill it.

> If this change is acceptable, then I think the new service should be called
> systemd-time-wait-synchronized (analogous to systemd-networkd-wait-online,
> as Lennart suggested) as it has nothing to do with timesyncd.  Further, it
> should have its own build option so it can be enabled independently of
> timesyncd (e.g. on embedded systems that will use ntpd with GPS to set the
> system time).

Well, even though you could use them separately, and we should support
that if it's easy to I doubt we need to clarify that in the naming. I
mean, other NTP implementations are likely to have their own
implementations of such wait functionality (I think at least chrony
has?), and they might do different stuff on top of waiting for the
mere NTP sync bit in the kernel, hence I doubt there's too much value
in making our implementation overly generic.

Lennart

-- 
Lennart Poettering, Red Hat
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[prev in list] [next in list] [prev in thread] [next in thread]