[gentoo-user] start ntpdate after network....

Discussion:

(too old to reply)

Tamer Higazi

2019-03-10 21:20:02 UTC

Hi people,

I have my gentoo system running with systemd.

I figured out that ntpdate is getting started before network is up.
I am not yet very familiar with systemd.

Can somebody of you tell me how to fix that, that "ntpdate" is started
the moment network devices are up ?

for any response and ideas, thank you!

best, Tamer

Rich Freeman

2019-03-10 21:40:01 UTC

Permalink

Post by Tamer Higazi
I have my gentoo system running with systemd.
I figured out that ntpdate is getting started before network is up.
I am not yet very familiar with systemd.
Can somebody of you tell me how to fix that, that "ntpdate" is started
the moment network devices are up ?

How is ntpdate being run? If you're using the supplied unit then it
should default to starting after network-online.target, which if
you're using a network manager started by systemd should delay it
until the network is running.

Now, if you're starting ntpdate in some other way then you'd need to
make sure that the network is online, and if you're starting the
network without using a supplied systemd unit then you'd need to make
sure systemd is aware of when it is up.

Basically, it should just work for the most part if you're using the
supplied units, but you don't mention much about your configuration
and Gentoo users do have a tendency to roll up their sleeves and do
things in scripts/etc.

The output of something like "systemctl status ntpdate" or "journalctl
-ab -u ntpdate" might be helpful. I'm not sure how you're configuring
your network (networkd, etc)? That would also be useful to know, as
well as the journal log for the associated units.

Systemd is highly dependency-driven and parallel, so issues like this
are mostly the result of failing to declare a dependency somewhere
(either on the network side or the ntp side). If you're using openrc
in parallel mode you need to do the same, and again that should be
taken care of out of the box if you're using the supplied services,
but if you roll your own you also have to be careful.

--
Rich

Tamer Higazi

2019-03-10 22:50:01 UTC

Permalink

Hi Rich,

Thank you for your response.

I am using the units that are supplied with gentoo....
I just restarted my machine and I get this output "systemctl status
ntpdate":

* ntpdate.service - Set time via NTP using ntpdate
   Loaded: loaded (/lib/systemd/system/ntpdate.service; enabled; vendor
preset: disabled)
Drop-In: /etc/systemd/system/ntpdate.service.d
           `-00gentoo.conf
   Active: failed (Result: exit-code) since Mon 2019-03-11 00:33:37
CET; 2min 30s ago
Process: 4553 ExecStart=/usr/sbin/ntpdate -b -u $SERVER (code=exited,
status=1/FAILURE)
Main PID: 4553 (code=exited, status=1/FAILURE)

Mar 11 00:33:36 localhost systemd[1]: Starting Set time via NTP using
ntpdate...
Mar 11 00:33:37 localhost ntpdate[4553]: Exiting, name server cannot be
used: Temporary failure in name resolution (-3)11 Mar 00:33:37
ntpdate[4553]: name server cannot be used: Temporary failure in name
resolution (-3)
Mar 11 00:33:37 localhost systemd[1]: ntpdate.service: Main process
exited, code=exited, status=1/FAILURE
Mar 11 00:33:37 localhost systemd[1]: ntpdate.service: Failed with
result 'exit-code'.
Mar 11 00:33:37 localhost systemd[1]: Failed to start Set time via NTP
using ntpdate.

and for the output looks like this:

-- Logs begin at Tue 2019-02-19 08:58:02 CET, end at Mon 2019-03-11
00:34:43 CET. --
Mar 11 00:33:36 localhost systemd[1]: Starting Set time via NTP using
ntpdate...
Mar 11 00:33:37 localhost ntpdate[4553]: Exiting, name server cannot be
used: Temporary failure in name resolution (-3)11 Mar 00:33:37
ntpdate[4553]: name server cannot be used: Temporary failure in name
resolution (-3)
Mar 11 00:33:37 localhost systemd[1]: ntpdate.service: Main process
exited, code=exited, status=1/FAILURE
Mar 11 00:33:37 localhost systemd[1]: ntpdate.service: Failed with
result 'exit-code'.
Mar 11 00:33:37 localhost systemd[1]: Failed to start Set time via NTP
using ntpdate.

If i start by hand, after the system is up with "systemctl start ntpdate":

* ntpdate.service - Set time via NTP using ntpdate
   Loaded: loaded (/lib/systemd/system/ntpdate.service; enabled; vendor
preset: disabled)
Drop-In: /etc/systemd/system/ntpdate.service.d
           `-00gentoo.conf
   Active: active (exited) since Sun 2019-03-10 23:38:36 CET; 2s ago
Process: 5093 ExecStart=/usr/sbin/ntpdate -b -u $SERVER (code=exited,
status=0/SUCCESS)
Main PID: 5093 (code=exited, status=0/SUCCESS)

Mar 11 00:37:59 localhost systemd[1]: Starting Set time via NTP using
ntpdate...
Mar 10 23:38:36 localhost ntpdate[5093]: 10 Mar 23:38:36 ntpdate[5093]:
step time server 162.23.41.10 offset -3573.367681 sec
Mar 10 23:38:36 localhost systemd[1]: Started Set time via NTP using
ntpdate.

also the result here looks different ( journalctl -ab -u ntpdate) by
executing manually:

Mar 10 23:38:36 localhost ntpdate[5093]: 10 Mar 23:38:36 ntpdate[5093]:
step time server 162.23.41.10 offset -3573.367681 sec
Mar 10 23:38:36 localhost systemd[1]: Started Set time via NTP using
ntpdate.

then everything looks fine...

Any ideas ?

best, Tamer

Post by Rich Freeman

How is ntpdate being run? If you're using the supplied unit then it
should default to starting after network-online.target, which if
you're using a network manager started by systemd should delay it
until the network is running.
Now, if you're starting ntpdate in some other way then you'd need to
make sure that the network is online, and if you're starting the
network without using a supplied systemd unit then you'd need to make
sure systemd is aware of when it is up.
Basically, it should just work for the most part if you're using the
supplied units, but you don't mention much about your configuration
and Gentoo users do have a tendency to roll up their sleeves and do
things in scripts/etc.
The output of something like "systemctl status ntpdate" or "journalctl
-ab -u ntpdate" might be helpful. I'm not sure how you're configuring
your network (networkd, etc)? That would also be useful to know, as
well as the journal log for the associated units.
Systemd is highly dependency-driven and parallel, so issues like this
are mostly the result of failing to declare a dependency somewhere
(either on the network side or the ntp side). If you're using openrc
in parallel mode you need to do the same, and again that should be
taken care of out of the box if you're using the supplied services,
but if you roll your own you also have to be careful.

Rich Freeman

2019-03-10 23:00:02 UTC

Permalink

Post by Tamer Higazi
Mar 11 00:33:37 localhost ntpdate[4553]: Exiting, name server cannot be
used: Temporary failure in name resolution (-3)11 Mar 00:33:37
ntpdate[4553]: name server cannot be used: Temporary failure in name
resolution (-3)

Ok, you didn't mention what you're using for a network manager. How
is the network interface being configured in the first place? There
are several ways that it is commonly done.

Also, what are you using for DNS? In particular, are you running a
local DNS server, or are you relying on a network-supplied DNS server?
How is /etc/resolv.conf being created (likely by the network manager,
but maybe it is being done in another way).

ntpdate by default depends on network-online.target and not on
nss-lookup.target, which can sometimes lead to issues if you're
running a DNS server that isn't online when the network is online
(such as a local server).

--
Rich

Neil Bothwick

2019-03-11 08:30:02 UTC

Permalink

Post by Rich Freeman

Post by Tamer Higazi
Mar 11 00:33:37 localhost ntpdate[4553]: Exiting, name server cannot
be used: Temporary failure in name resolution (-3)11 Mar 00:33:37
ntpdate[4553]: name server cannot be used: Temporary failure in name
resolution (-3)

Also, where is the NTP server? On the local network or external?

Post by Rich Freeman
ntpdate by default depends on network-online.target and not on
nss-lookup.target, which can sometimes lead to issues if you're
running a DNS server that isn't online when the network is online
(such as a local server).

The definitions of when a network is actually online are variable, see
https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/

You may need to add NetworkManager-wait-online.service or
systemd-networkd-wait-online.service to the dependencies for ntpdate,
which is possibly why Rich is asking how you manage your network.

I don't use ntpdate here but systemd-timesyncd.service instead, which
seems to handle this better.

--
Neil Bothwick

An atheist is someone who feels he has no invisible means of support.

Tamer Higazi

2019-03-15 00:10:02 UTC

Permalink

Hei Neil,

The NTPServer is in the internet, standard gentoo ntp.conf file:

# Pools for Gentoo users
server 0.gentoo.pool.ntp.org
server 1.gentoo.pool.ntp.org
server 2.gentoo.pool.ntp.org
server 3.gentoo.pool.ntp.org

I am using systemd-networkd, regarding the gentoo systemd network guide:
https://wiki.gentoo.org/wiki/Systemd#systemd-networkd

/etc/systemd/network/50-dhcp.network looks like this:

[Match]
Name=en*

[Network]
DHCP=yes
IPv6PrivacyExtensions=true

[DHCP]
UseDNS=false

/etc/systemd/resolved.conf looks like this:

[Resolve]
DNS=1.1.1.1 1.0.0.1 2606:4700:4700::1111 2606:4700:4700::1001

ifconfig -a:

enp6s0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
        ether 00:01:2e:80:8c:2d txqueuelen 1000 (Ethernet)
        RX packets 0 bytes 0 (0.0 B)
        RX errors 0 dropped 0 overruns 0 frame 0
        TX packets 0 bytes 0 (0.0 B)
        TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

enp7s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
        inet 192.168.0.248 netmask 255.255.255.0 broadcast 192.168.0.255
        inet6 fe80::201:2eff:fe80:8c2e prefixlen 64 scopeid 0x20<link>
        inet6 xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:fe80:8c2e prefixlen 64
scopeid 0x0<global>
        ether 00:01:2e:80:8c:2e txqueuelen 1000 (Ethernet)
        RX packets 123185 bytes 136156971 (129.8 MiB)
        RX errors 0 dropped 2 overruns 0 frame 0
        TX packets 46499 bytes 8831194 (8.4 MiB)
        TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

(i replaced ipv6 address with xxx....)

Post by Neil Bothwick

Post by Rich Freeman

Post by Tamer Higazi
Mar 11 00:33:37 localhost ntpdate[4553]: Exiting, name server cannot
be used: Temporary failure in name resolution (-3)11 Mar 00:33:37
ntpdate[4553]: name server cannot be used: Temporary failure in name
resolution (-3)

Also, where is the NTP server? On the local network or external?

The definitions of when a network is actually online are variable, see
https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/
You may need to add NetworkManager-wait-online.service or
systemd-networkd-wait-online.service to the dependencies for ntpdate,
which is possibly why Rich is asking how you manage your network.
I don't use ntpdate here but systemd-timesyncd.service instead, which
seems to handle this better.

Tamer Higazi

2019-04-13 10:30:01 UTC

Permalink

Hi people,

As systemd handles netwok, I can do it as well with time!

You can safely delete every ntp package and edit the file:
/etc/systemd/timesyncd.conf

and change its content to:

[Time]
NTP=0.ch.pool.ntp.org 1.ch.pool.ntp.org 2.ch.pool.ntp.org 3.ch.pool.ntp.org
FallbackNTP=0.gentoo.pool.ntp.org 1.gentoo.pool.ntp.org
2.gentoo.pool.ntp.org 3.gentoo.pool.ntp.org

enable systemd-timesync with:

systemctl enable systemd-timesyncd

and done!
When I restart, after network is up the time is synchronized in
background until lightdm is up.....

best, Tamer

Post by Neil Bothwick

Post by Rich Freeman

Post by Tamer Higazi
Mar 11 00:33:37 localhost ntpdate[4553]: Exiting, name server cannot
be used: Temporary failure in name resolution (-3)11 Mar 00:33:37
ntpdate[4553]: name server cannot be used: Temporary failure in name
resolution (-3)

Also, where is the NTP server? On the local network or external?

The definitions of when a network is actually online are variable, see
https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/
You may need to add NetworkManager-wait-online.service or
systemd-networkd-wait-online.service to the dependencies for ntpdate,
which is possibly why Rich is asking how you manage your network.
I don't use ntpdate here but systemd-timesyncd.service instead, which
seems to handle this better.

Manuel McLure

2019-03-10 23:30:02 UTC

Permalink

Do you have IPV6 enabled at all on your network? I have seen problems in
the past where the DHCP client (dhcpcd) would return as soon as it got an
IPV6 address so processes that depended on an IPV4 address would fail to
start - in my case I've seen it both with MySQL and with NFS mounts.

The solution (if you're using dhcpcd as your DHCP client) is to add either

waitip 4

or

waitip 4 6

to the end of your /etc/dhcpcd.conf file.

--
Manuel A. McLure WW1FA <***@mclure.org> <http://www.mclure.org>
...for in Ulthar, according to an ancient and significant law,
no man may kill a cat. -- H.P. Lovecraft

Tamer Higazi

2019-03-14 22:40:01 UTC

Permalink

Hi Manuel,

I tried that one you advised. Still not successfull .

best, Tamer

Post by Tamer Higazi
Mar 11 00:33:36 localhost systemd[1]: Starting Set time via NTP using
ntpdate...
Mar 11 00:33:37 localhost ntpdate[4553]: Exiting, name server cannot be
used: Temporary failure in name resolution (-3)11 Mar 00:33:37
ntpdate[4553]: name server cannot be used: Temporary failure in name
resolution (-3)
Mar 11 00:33:37 localhost systemd[1]: ntpdate.service: Main process
exited, code=exited, status=1/FAILURE
Mar 11 00:33:37 localhost systemd[1]: ntpdate.service: Failed with
result 'exit-code'.
Mar 11 00:33:37 localhost systemd[1]: Failed to start Set time via NTP
using ntpdate.
Do you have IPV6 enabled at all on your network? I have seen problems
in the past where the DHCP client (dhcpcd) would return as soon as it
got an IPV6 address so processes that depended on an IPV4 address
would fail to start - in my case I've seen it both with MySQL and with
NFS mounts.
The solution (if you're using dhcpcd as your DHCP client) is to add either
waitip 4
or
waitip 4 6
to the end of your /etc/dhcpcd.conf file.
--
<http://www.mclure.org>
...for in Ulthar, according to an ancient and significant law,
no man may kill a cat. -- H.P. Lovecraft