[gentoo-user] ntp-client slows down the boot process

[gentoo-user] ntp-client slows down the boot process

[YUE Daian]

Hi folks,

I use ntp-client to synchronize the date/time of my Gentoo system.

I added it to the default boot level (OpenRC), however it seriously
slows down the boot process (around 10 seconds or so).

Is there any way to make it faster? Or am I using the wrong service?

Thanks in advance!

Danny

Re: [gentoo-user] ntp-client slows down the boot process

[Peter Humphrey]

On Friday, 26 July 2019 05:36:29 BST YUE Daian wrote:
> Hi folks,
> 
> I use ntp-client to synchronize the date/time of my Gentoo system.
> 
> I added it to the default boot level (OpenRC), however it seriously
> slows down the boot process (around 10 seconds or so).
> 
> Is there any way to make it faster? Or am I using the wrong service?

It may be taking time to gather entropy. In that case you could install sys-
apps/haveged and add it to your boot run-level.

-- 
Regards,
Peter.

Re: [gentoo-user] ntp-client slows down the boot process

[YUE Daian]

On 2019-07-26 09:30, Peter Humphrey <peter@prh.myzen.co.uk> wrote:
> On Friday, 26 July 2019 05:36:29 BST YUE Daian wrote:
>> Hi folks,
>> 
>> I use ntp-client to synchronize the date/time of my Gentoo system.
>> 
>> I added it to the default boot level (OpenRC), however it seriously
>> slows down the boot process (around 10 seconds or so).
>> 
>> Is there any way to make it faster? Or am I using the wrong service?
>
> It may be taking time to gather entropy. In that case you could install sys-
> apps/haveged and add it to your boot run-level.
>
> -- 
> Regards,
> Peter.

Well, I presume the problem is related to ntpdate itself.

It is working in a blocking way that the remaining boot processes have
to wait until the time got synchronized.

Is there any way to make it update the time in an asynchronize way?
Or should I use ntpd instead?

Thanks.

Danny

Re: [gentoo-user] ntp-client slows down the boot process

[Mick]

[-- Attachment #1: Type: text/plain, Size: 1222 bytes --]

On Friday, 26 July 2019 15:23:11 BST YUE Daian wrote:
> On 2019-07-26 09:30, Peter Humphrey <peter@prh.myzen.co.uk> wrote:
> > On Friday, 26 July 2019 05:36:29 BST YUE Daian wrote:
> >> Hi folks,
> >> 
> >> I use ntp-client to synchronize the date/time of my Gentoo system.
> >> 
> >> I added it to the default boot level (OpenRC), however it seriously
> >> slows down the boot process (around 10 seconds or so).
> >> 
> >> Is there any way to make it faster? Or am I using the wrong service?
> > 
> > It may be taking time to gather entropy. In that case you could install
> > sys- apps/haveged and add it to your boot run-level.
> 
> Well, I presume the problem is related to ntpdate itself.
> 
> It is working in a blocking way that the remaining boot processes have
> to wait until the time got synchronized.

Or, until the network is up and a time server can be contacted?


> Is there any way to make it update the time in an asynchronize way?
> Or should I use ntpd instead?
> 
> Thanks.
> 
> Danny

I don't run ntp-client here, but have a look at its startup script and any 
dependencies defined therein, then perhaps tweak /etc/rc.conf.  Does setting 
rc_depend_strict="NO" makes a difference?

-- 
Regards,

Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] ntp-client slows down the boot process

[Ralph Seichter]

* YUE Daian:

> I added [ntp-client] to the default boot level (OpenRC), however it
> seriously slows down the boot process (around 10 seconds or so).

Launching 'clamd' can hold up a reboot for a minute or longer, so ten
seconds do not seem that bad to me.

> Is there any way to make it faster?

Personally, I gladly wait for a couple of seconds and know that the
clock is correct, but if it bothers you too much, you can try setting
rc_parallel="YES" in /etc/rc.conf .

-Ralph

Re: [gentoo-user] ntp-client slows down the boot process

[YUE Daian]

On 2019-07-26 15:55, Mick <michaelkintzios@gmail.com> wrote:
> On Friday, 26 July 2019 15:23:11 BST YUE Daian wrote:
>> On 2019-07-26 09:30, Peter Humphrey <peter@prh.myzen.co.uk> wrote:
>> > On Friday, 26 July 2019 05:36:29 BST YUE Daian wrote:
>> >> Hi folks,
>> >> 
>> >> I use ntp-client to synchronize the date/time of my Gentoo system.
>> >> 
>> >> I added it to the default boot level (OpenRC), however it seriously
>> >> slows down the boot process (around 10 seconds or so).
>> >> 
>> >> Is there any way to make it faster? Or am I using the wrong service?
>> > 
>> > It may be taking time to gather entropy. In that case you could install
>> > sys- apps/haveged and add it to your boot run-level.
>> 
>> Well, I presume the problem is related to ntpdate itself.
>> 
>> It is working in a blocking way that the remaining boot processes have
>> to wait until the time got synchronized.
>
> Or, until the network is up and a time server can be contacted?
>
>
>> Is there any way to make it update the time in an asynchronize way?
>> Or should I use ntpd instead?
>> 
>> Thanks.
>> 
>> Danny
>
> I don't run ntp-client here, but have a look at its startup script and any 
> dependencies defined therein, then perhaps tweak /etc/rc.conf.  Does setting 
> rc_depend_strict="NO" makes a difference?
>
> -- 
> Regards,
>
> Mick

In fact since my PC is using a wire connection, the network starting
process takes very short time.

It is the problem of slow NTP itself.

I tried "rc_depend_strict" but no luck...

Re: [gentoo-user] ntp-client slows down the boot process

[YUE Daian]

On 2019-07-26 17:15, Ralph Seichter <abbot@monksofcool.net> wrote:
> * YUE Daian:
>
>> I added [ntp-client] to the default boot level (OpenRC), however it
>> seriously slows down the boot process (around 10 seconds or so).
>
> Launching 'clamd' can hold up a reboot for a minute or longer, so ten
> seconds do not seem that bad to me.
>
>> Is there any way to make it faster?
>
> Personally, I gladly wait for a couple of seconds and know that the
> clock is correct, but if it bothers you too much, you can try setting
> rc_parallel="YES" in /etc/rc.conf .
>
> -Ralph

I switched to a faster NTP server. It still takes some seconds but
better than before.

Maybe you are right. Having correct system time is more important than
several seconds...

By the way does "rc_parallel" really makes a difference?
I tried it once before but did not really see much difference.

Thanks!

Re: [gentoo-user] ntp-client slows down the boot process

[Rich Freeman]

On Fri, Jul 26, 2019 at 11:32 AM YUE Daian <sheepduke@gmail.com> wrote:
>
> I switched to a faster NTP server. It still takes some seconds but
> better than before.
>
> Maybe you are right. Having correct system time is more important than
> several seconds...

You're never going to make NTP fast unless you're using a VERY
low-latency server - like something on your own LAN.  That is just the
nature of the protocol - it has to do a round trip, and of course to
do anything it needs the interface up, DNS, and so on, and all of
these will be starting from cold caches.  If you have non-local DNS
and non-local NTP then that is multiple round-trips to the internet.

>
> By the way does "rc_parallel" really makes a difference?
> I tried it once before but did not really see much difference.

I haven't used OpenRC in ages, but I'm guessing that NTP is set as a
dependency somewhere in the chain.  It does make sense - lots of
services do not like abrupt time changes so generic dependencies will
probably assume that you want to set your clocks before starting
anything.

I'm not sure how ntpdate implements time changes.  I know that ntpd
will slew the clock gradually for small corrections, but it is a
daemon so it can easily implement something like that.  A one-shot
correction will probably be instant, and thus will be more of an
impact on other services.

You can probably adjust the dependencies to suit your tastes, but of
course you'll have to keep in mind that time changes for running
services might or might not be a problem.  If you're fairly confident
in your hardware clock accuracy (assuming you even have one) that
isn't a big deal.  If you're talking about some system that doesn't
keep time when powered off/etc then you probably don't want your
database server to spin up thinking it is 1980 or whatever its epoch
is.

I did a quick check of what is being done with systemd and ntpdate is
needed before the time-sync target, and that is needed before starting
cron or any timer units (obvious requirement), and it is also required
before spinning up libvirt guests, which also makes sense so that
those initialize with a clean clock, though if they update themselves
maybe that isn't a hard requirement.

-- 
Rich

Re: [gentoo-user] ntp-client slows down the boot process

[Mick]

[-- Attachment #1: Type: text/plain, Size: 2673 bytes --]

On Friday, 26 July 2019 16:49:25 BST Rich Freeman wrote:
> On Fri, Jul 26, 2019 at 11:32 AM YUE Daian <sheepduke@gmail.com> wrote:
> > I switched to a faster NTP server. It still takes some seconds but
> > better than before.
> > 
> > Maybe you are right. Having correct system time is more important than
> > several seconds...
> 
> You're never going to make NTP fast unless you're using a VERY
> low-latency server - like something on your own LAN.  That is just the
> nature of the protocol - it has to do a round trip, and of course to
> do anything it needs the interface up, DNS, and so on, and all of
> these will be starting from cold caches.  If you have non-local DNS
> and non-local NTP then that is multiple round-trips to the internet.
> 
> > By the way does "rc_parallel" really makes a difference?
> > I tried it once before but did not really see much difference.
> 
> I haven't used OpenRC in ages, but I'm guessing that NTP is set as a
> dependency somewhere in the chain.  It does make sense - lots of
> services do not like abrupt time changes so generic dependencies will
> probably assume that you want to set your clocks before starting
> anything.
> 
> I'm not sure how ntpdate implements time changes.  I know that ntpd
> will slew the clock gradually for small corrections, but it is a
> daemon so it can easily implement something like that.  A one-shot
> correction will probably be instant, and thus will be more of an
> impact on other services.
> 
> You can probably adjust the dependencies to suit your tastes, but of
> course you'll have to keep in mind that time changes for running
> services might or might not be a problem.  If you're fairly confident
> in your hardware clock accuracy (assuming you even have one) that
> isn't a big deal.  If you're talking about some system that doesn't
> keep time when powered off/etc then you probably don't want your
> database server to spin up thinking it is 1980 or whatever its epoch
> is.
> 
> I did a quick check of what is being done with systemd and ntpdate is
> needed before the time-sync target, and that is needed before starting
> cron or any timer units (obvious requirement), and it is also required
> before spinning up libvirt guests, which also makes sense so that
> those initialize with a clean clock, though if they update themselves
> maybe that isn't a hard requirement.

Just a thought - is the hwclock service in the boot run level and running?  I 
think it will restore the time stored on the hwclock to the system and then 
gradually update it as the ntp-client starts communicating with various time 
servers.  At least this is how chrony does it.

-- 
Regards,

Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[gentoo-user] Re: ntp-client slows down the boot process

[Grant Edwards]

On 2019-07-26, YUE Daian <sheepduke@gmail.com> wrote:

> By the way does "rc_parallel" really makes a difference?

<cynic-mode>
Yes.  It guarantees that when you do have boot problems, you'll never
be able to figure out the real problem.
</cynic-mode>

Having more parallel boot operations used to be one of the
"advantages" touted by some pro-systemd people.  I always thought it
sounded like a horrible idea and an excellent reason to stick with
openrc.

I have enough problems figuring out package build failures with -j2.  :/

--
Grant

[gentoo-user] Re: ntp-client slows down the boot process

[Ian Zimmerman]

On 2019-07-27 01:27, Grant Edwards wrote:

> > By the way does "rc_parallel" really makes a difference?
> 
> <cynic-mode>
> Yes.  It guarantees that when you do have boot problems, you'll never
> be able to figure out the real problem.
> </cynic-mode>
> 
> Having more parallel boot operations used to be one of the
> "advantages" touted by some pro-systemd people.  I always thought it
> sounded like a horrible idea and an excellent reason to stick with
> openrc.

Well, to play the anti-$DEITY advocate, you may also say that
parallelizing helps you discover bugs in the dependencies that you
otherwise never would.

I have run fedora with systemd for a while, and I was able to make the
boot wicked fast.  But it wasn't automatic, not due to systemd itself
but due to packages like NetworkManager doing incredibly wasteful
things by default.

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
To reply privately _only_ on Usenet and on broken lists
which rewrite From, fetch the TXT record for no-use.mooo.com.

Re: [gentoo-user] Re: ntp-client slows down the boot process

[Aidan Harris]

[-- Attachment #1: Type: text/plain, Size: 1823 bytes --]

On 27/07/2019 06:13, Ian Zimmerman wrote:

> Well, to play the anti-$DEITY advocate, you may also say that
> parallelizing helps you discover bugs in the dependencies that you
> otherwise never would.
> 
> I have run fedora with systemd for a while, and I was able to make the
> boot wicked fast.  But it wasn't automatic, not due to systemd itself
> but due to packages like NetworkManager doing incredibly wasteful
> things by default.
> 

Speaking parallel of bugs...

I run openrc with rc_parallel enabled and I end up booting so fast that 
by the time ntp-client starts DNS resolution is not properly available 
yet (I use a local DNS resolver so even though networking is up my local 
resolver takes a while - a small while, but enough of a while to be a 
problem - to be "ready") so the service fails to start. To work around 
this I added a few lines of shell to the start function:


# We boot so fast dns doesn't come up quickly enough
# By querying dns with nslookup we (hopefully) wait just long enough for 
it to come up properly
egrep '^server' /etc/ntp.conf | while read -r server
do
	set -- $server
	server="$2"
	nslookup "$server" > /dev/null 2>&1 && break
done

The second problem I had is even though I'm using rc_parallel ntp-client 
likes to block the rest of the boot (this is a laptop, I really don't 
need to block the whole boot just to make sure the time is set 
correctly). To work around that I used another hack by starting it from 
an @reboot cronjob.

I don't know what the proper idiomatic fix for these issues are, but 
booting too fast is a real problem (a problem that disappears if I 
disable rc_parallel but I want to boot fast!).

I've attached a bootchart showing ntp-client started from the default 
runlevel versus started via the @reboot cronjob (the difference is plain 
to see).

[-- Attachment #2: bootchart.png --]
[-- Type: image/png, Size: 392949 bytes --]

[-- Attachment #3: bootchart_ntp-client-default-runlevel.png --]
[-- Type: image/png, Size: 425501 bytes --]

[gentoo-user] Re: ntp-client slows down the boot process

[Ian Zimmerman]

On 2019-07-27 07:42, Aidan Harris wrote:

> I run openrc with rc_parallel enabled and I end up booting so fast
> that by the time ntp-client starts DNS resolution is not properly
> available yet (I use a local DNS resolver so even though networking is
> up my local resolver takes a while - a small while, but enough of a
> while to be a problem - to be "ready") so the service fails to
> start. To work around this I added a few lines of shell to the start
> function:

I take it that you stick with the default ntp configuration, with
syncing from a pool.  I do not; I have found a few public stratum 1
servers relatively close to me, and I use them in general, via their IP
addresses and not via their DNS names.

On my desktop and on my Pi, which do not need mobility, I don't even do
that: I sync to my router.  It makes a fine stratum 2 NTP server :-)

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
To reply privately _only_ on Usenet and on broken lists
which rewrite From, fetch the TXT record for no-use.mooo.com.

Re: [gentoo-user] Re: ntp-client slows down the boot process

[YUE Daian]

On 2019-07-27 09:20, Ian Zimmerman <itz@very.loosely.org> wrote:
> On 2019-07-27 07:42, Aidan Harris wrote:
>
>> I run openrc with rc_parallel enabled and I end up booting so fast
>> that by the time ntp-client starts DNS resolution is not properly
>> available yet (I use a local DNS resolver so even though networking is
>> up my local resolver takes a while - a small while, but enough of a
>> while to be a problem - to be "ready") so the service fails to
>> start. To work around this I added a few lines of shell to the start
>> function:
>
> I take it that you stick with the default ntp configuration, with
> syncing from a pool.  I do not; I have found a few public stratum 1
> servers relatively close to me, and I use them in general, via their IP
> addresses and not via their DNS names.
>
> On my desktop and on my Pi, which do not need mobility, I don't even do
> that: I sync to my router.  It makes a fine stratum 2 NTP server :-)
>
> -- 
> Please don't Cc: me privately on mailing lists and Usenet,
> if you also post the followup to the list or newsgroup.
> To reply privately _only_ on Usenet and on broken lists
> which rewrite From, fetch the TXT record for no-use.mooo.com.

You inspired me.

Maybe I can build a NTP server on my Rasp Pi in the local network and
sync from it.

It should be a little bit faster and save me...well, 3 seconds ;-)