Discussion:
alternative approach to waiting for system time to be set
(too old to reply)
Peter A. Bigot
2018-03-19 01:45:01 UTC
Permalink
Like others I'd like to use systemd to defer starting a service until
the system time has been set accurately.  Previous approaches to
resolving issue #5097 don't seem to be going anywhere.

https://github.com/pabigot/timesyncwait has my proposed solution: a
standalone service that blocks until adjtimex(2) confirms that something
has told the kernel its realtime clock is synchronized. It also provides
a new time-synchronized.target so it can be installed alongside an
unmodified timesyncd.

Initial tests show this meets my needs.  I'd be willing to rework it as
a patch to systemd if there's consensus the approach is reasonable.

Peter

Mar 15 17:14:17 raspberrypi3 systemd[1]: Starting Wait Until Kernel Time
Synchronized...
Mar 15 17:14:17 raspberrypi3 timesyncwait[107]: adjtime state 5 status
40 time 1521134057.408590
Mar 19 01:04:35 raspberrypi3 timesyncwait[107]: adjtime state 0 status
2000 time 1521421475.316852
Mar 19 01:04:35 raspberrypi3 systemd[1]: Started Wait Until Kernel Time
Synchronized.

References:
* https://github.com/systemd/systemd/issues/5097
* https://github.com/LukeShu/systemd-timesyncd-wait
*
https://lists.freedesktop.org/archives/systemd-devel/2014-November/025131.html
* https://lists.freedesktop.org/archives/systemd-devel/2017-May/038952.html
Jérémy Rosen
2018-03-19 08:23:02 UTC
Permalink
Maybe start a github pull-request ? things seems to be less forgotten
that way.

since your code already exist, creating a first PR should not be too
much work...
Post by Peter A. Bigot
Like others I'd like to use systemd to defer starting a service until
the system time has been set accurately.  Previous approaches to
resolving issue #5097 don't seem to be going anywhere.
https://github.com/pabigot/timesyncwait has my proposed solution: a
standalone service that blocks until adjtimex(2) confirms that
something has told the kernel its realtime clock is synchronized. It
also provides a new time-synchronized.target so it can be installed
alongside an unmodified timesyncd.
Initial tests show this meets my needs.  I'd be willing to rework it
as a patch to systemd if there's consensus the approach is reasonable.
Peter
Mar 15 17:14:17 raspberrypi3 systemd[1]: Starting Wait Until Kernel
Time Synchronized...
Mar 15 17:14:17 raspberrypi3 timesyncwait[107]: adjtime state 5 status
40 time 1521134057.408590
Mar 19 01:04:35 raspberrypi3 timesyncwait[107]: adjtime state 0 status
2000 time 1521421475.316852
Mar 19 01:04:35 raspberrypi3 systemd[1]: Started Wait Until Kernel
Time Synchronized.
* https://github.com/systemd/systemd/issues/5097
* https://github.com/LukeShu/systemd-timesyncd-wait
*
https://lists.freedesktop.org/archives/systemd-devel/2014-November/025131.html
*
https://lists.freedesktop.org/archives/systemd-devel/2017-May/038952.html
_______________________________________________
systemd-devel mailing list
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
SMILE <http://www.smile.eu/>

20 rue des Jardins
92600 AsniÚres-sur-Seine


*Jérémy ROSEN*
Architecte technique
Responsable de l'expertise Smile-ECS

email ***@smile.fr <mailto:***@smile.fr>
phone +33141402967
url http://www.smile.eu

Twitter <https://twitter.com/GroupeSmile> Facebook
<https://www.facebook.com/smileopensource> LinkedIn
<https://www.linkedin.com/company/smile> Github
<https://github.com/Smile-SA>


Découvrez l’univers Smile, rendez-vous sur smile.eu
<http://smile.eu/?utm_source=signature&utm_medium=email&utm_campaign=signature>

eco Pour la planÚte, n'imprimez ce mail que si c'est nécessaire
Lennart Poettering
2018-03-19 21:17:49 UTC
Permalink
Like others I'd like to use systemd to defer starting a service until the
system time has been set accurately.  Previous approaches to resolving issue
#5097 don't seem to be going anywhere.
https://github.com/pabigot/timesyncwait has my proposed solution: a
standalone service that blocks until adjtimex(2) confirms that something has
told the kernel its realtime clock is synchronized. It also provides a new
time-synchronized.target so it can be installed alongside an unmodified
timesyncd.
Initial tests show this meets my needs.  I'd be willing to rework it as a
patch to systemd if there's consensus the approach is reasonable.
Yeah, I figure this makes sense to have. But it would need some
updates to match what our CODING_STYLE docs suggest (starting with 8ch
indenting).

Would be great if you could rework it accordingly and submit it as PR.

Lennart
--
Lennart Poettering, Red Hat
Peter A. Bigot
2018-03-20 05:57:12 UTC
Permalink
Post by Lennart Poettering
Like others I'd like to use systemd to defer starting a service until the
system time has been set accurately.  Previous approaches to resolving issue
#5097 don't seem to be going anywhere.
https://github.com/pabigot/timesyncwait has my proposed solution: a
standalone service that blocks until adjtimex(2) confirms that something has
told the kernel its realtime clock is synchronized. It also provides a new
time-synchronized.target so it can be installed alongside an unmodified
timesyncd.
Initial tests show this meets my needs.  I'd be willing to rework it as a
patch to systemd if there's consensus the approach is reasonable.
Yeah, I figure this makes sense to have. But it would need some
updates to match what our CODING_STYLE docs suggest (starting with 8ch
indenting).
Would be great if you could rework it accordingly and submit it as PR.
https://github.com/systemd/systemd/pull/8494

Peter
Peter A. Bigot
2018-03-20 13:54:47 UTC
Permalink
Post by Peter A. Bigot
Post by Lennart Poettering
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).

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).

If this change is not acceptable, then a new synchronization point named
something like "time-sync-for-reals.target" should be defined, and
that's starting to look ugly.

What do y'all think?

Peter

References:
* http://refspecs.linuxbase.org/LSB_2.0.1/LSB-PDA/LSB-PDA/facilname.html
Lennart Poettering
2018-03-20 15:19:14 UTC
Permalink
Post by Peter A. Bigot
Post by Lennart Poettering
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
Loading...