Systemd nss_lookup.target deleted to break ordering cycle

English Install/Boot/Login
1

I see this error in journalctl

Oct 04 13:33:12 hpprol2 systemd[1]: ntpd.service: Found ordering cycle on nss-lookup.target/start
Oct 04 13:33:12 hpprol2 systemd[1]: ntpd.service: Found dependency on named.service/start
Oct 04 13:33:12 hpprol2 systemd[1]: ntpd.service: Found dependency on time-sync.target/start
Oct 04 13:33:12 hpprol2 systemd[1]: ntpd.service: Found dependency on ntpd.service/start
Oct 04 13:33:12 hpprol2 systemd[1]: ntpd.service: Job nss-lookup.target/start deleted to break ordering cycle starting with ntpd.service/start

In /usr/lib/systemd/system/

  1. ntpd.service contains
[Unit]
Description=NTP Server Daemon
Documentation=man:ntpd(1)
**After=nss-lookup.target
...**
Before=time-sync.target
...

2 named.service contains

...
After=time-sync.target
Before=nss-lookup.target
Wants=nss-lookup.target
...
  1. time-sync.target contains
..
After=time-set.target
...
  1. nss-lookup.target contains only
[Unit]
Description=Host and Network Name Lookups
Documentation=man:systemd.special(7)
RefuseManualStart=yes

command “systemctl status nss-lookup.target” shows

     Loaded: loaded (/usr/lib/systemd/system/nss-lookup.target; static)
     Active: inactive (dead)
...
ntpd.service: Job nss-lookup.target/start deleted to break ordering cycle starting with ntpd.service/start

I have the filling that there is an incompatibily between ntpd.service and named.service about nss-lookup.target and time-sync.target.
nss-lookup.target cannot be manually started due to the “RefuseManualStart=yes”

any hints? Should I open a bug report about this?

Many thanks in advance
Philippe

2

I just checked one Tumbleweed system, and I am not seeing that problem.

Yes, I would suggest a bug report.

3

Are you using bind as DNS server?

4

Yes I use bind as DNS server. It is working correctly for my server and the laptop clients.

Regards
Philippe

5

I see the exact same issue on openSUSE 15.2

named.service causes a systemd ordering conflict if a system enables named and either chronyd or ntpd.

It looks to me like this is because named.service has “After=time-sync.target” defined but ntpd.service and chronyd.service both have “After=nss-lookup.target” defined.

I didn’t see this with openSUSE 15.1

Commenting out “[FONT=monospace][FONT=monospace][FONT=monospace][FONT=arial]After=time-sync.target” in named.service removes the conflict.[/FONT][/FONT][/FONT][FONT=monospace][FONT=monospace]
[/FONT][/FONT][/FONT]

6

By default Tumbleweed disables ntpd and chronyd:

erlangen:~ # systemctl list-unit-files ntp* chrony*
UNIT FILE              STATE    VENDOR PRESET
chrony-dnssrv@.service static   -            
chrony-wait.service    disabled disabled     
chronyd.service        **enabled**  disabled     
ntp-wait.service       disabled disabled     
ntpd.service           disabled disabled     
chrony-dnssrv@.timer   disabled disabled     

6 unit files listed.
erlangen:~ #

Try chrony: disable ntpd.service, enable chronyd.service.

7

Hi,

as I said in my post, the ordering conflict exists with both ntpd and chronyd, whichever is enabled. This is because named asks to be started after a time-sync target is reached but both time-sync services ask to be started after the nss-lookup target i.e. after named

It seems logical that ntpd or chronyd are going to need a name service to work properly so I think the issue is with named having a requirement for a time-sync service.

I’ve only seen this since upgrading to openSUSE 15.2 so something changed from 15.1, possibly when chronyd became the default instead of ntpd changes were made to various unit files (I am guessing) which broke the ordering dependencies.

8

Name resolution can fail at any moment, so robust program must retry it. In this case there is no reason to start it after name service, program would simply retry and eventually recover when name resolution becomes available.

Not to mention that system may not use DNS for this specific case at all.

I think the issue is with named having a requirement for a time-sync service.

With secure DNS correct time becomes rather critical.

9

Thanks I’ll try this.
I opened a bug report: 1177491 – systemd ordering cycle with nss-lookup.target

Regards
Philippe

10

I am wondering: named.service does no longer exist with systemd-246.6-2.1. Is your system out-of-date?

11

I can’t answer for the original poster but I see this problem on openSUSE Leap 15.2 (up to date with systemd-234-lp152.31.7.1.x86_64), and anyway, named.service is part of the bind package, not systemd.

12

My system is up to date (systemd is at 246.6-2.1) but named.service is installed by bind (currently 9.16.7-1.1) and is present since some years. When I installed named I needed installing also ntpd.

Regards
Philippe

13

Thanks for clarifying. I thought it would be a package like systemd-network but it’s part of BIND.

14

I tested this and on tumblewed also this solves the ordering cycle problem. I updated the bug report but still no answer :frowning:
Can this problem due to the fact that named.service is comming from bind and the other from systemd?

Regards
Philippe

15

Started named without any problems:

erlangen:~ # journalctl -b -u named.service -p notice --no-full  
-- Logs begin at Sat 2020-10-31 09:10:06 CET, end at Mon 2020-11-02 10:01:23 CET. -- 
Nov 02 09:56:36 erlangen named[23768]: starting BIND 9.16.7 (Stable Release) <id:6fd3eb7> 
Nov 02 09:56:36 erlangen named[23768]: running on Linux x86_64 5.9.1-1-default #1 SMP Mon Oct 26 07:02:23 UTC 2020 (435e92d) 
Nov 02 09:56:36 erlangen named[23768]: built with '--host=x86_64-suse-linux-gnu' '--build=x86_64-suse-linux-gnu' '--program-prefix=' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/includ… 
Nov 02 09:56:36 erlangen named[23768]: running as: named -t /var/lib/named -u named 
Nov 02 09:56:36 erlangen named[23768]: compiled by GCC 10.2.1 20200825 [revision c0746a1beb1ba073c7981eb09f55b3d993b32e5c] 
Nov 02 09:56:36 erlangen named[23768]: compiled with OpenSSL version: OpenSSL 1.1.1h  22 Sep 2020 
Nov 02 09:56:36 erlangen named[23768]: linked to OpenSSL version: OpenSSL 1.1.1h  22 Sep 2020 
Nov 02 09:56:36 erlangen named[23768]: compiled with libxml2 version: 2.9.10 
Nov 02 09:56:36 erlangen named[23768]: linked to libxml2 version: 20910 
Nov 02 09:56:36 erlangen named[23768]: compiled with json-c version: 0.15 
Nov 02 09:56:36 erlangen named[23768]: linked to json-c version: 0.15 
Nov 02 09:56:36 erlangen named[23768]: compiled with zlib version: 1.2.11 
Nov 02 09:56:36 erlangen named[23768]: linked to zlib version: 1.2.11 
Nov 02 09:56:36 erlangen named[23768]: ---------------------------------------------------- 
Nov 02 09:56:36 erlangen named[23768]: BIND 9 is maintained by Internet Systems Consortium, 
Nov 02 09:56:36 erlangen named[23768]: Inc. (ISC), a non-profit 501(c)(3) public-benefit 
Nov 02 09:56:36 erlangen named[23768]: corporation.  Support and training for BIND 9 are 
Nov 02 09:56:36 erlangen named[23768]: available at https://www.isc.org/support 
Nov 02 09:56:36 erlangen named[23768]: ---------------------------------------------------- 
Nov 02 09:56:36 erlangen named[23768]: adjusted limit on open files from 524288 to 1048576 
Nov 02 09:56:36 erlangen named[23768]: command channel listening on 127.0.0.1#953 
Nov 02 09:56:36 erlangen named[23768]: command channel listening on ::1#953 
Nov 02 09:56:36 erlangen named[23768]: all zones loaded 
Nov 02 09:56:36 erlangen named[23768]: running 
Nov 02 09:56:36 erlangen named[23768]: managed-keys-zone: Initializing automatic trust anchor management for zone '.'; DNSKEY ID 20326 is now trusted, waiving the normal 30-day waiting period. 
erlangen:~ #

But I am using chrony instead of ntp.

16

I think that chrony in place of ntp is not the problem ==> hodgepig saw in leap 15.2 the same problem with ntp or chrony.
I don’t have the problem when a new kernel is installed (and purge kernel is running at boot);
My feeling is that it can be race condition between different services: wicked, ppp@.service, ntpd.service, time-sync.target , named.service maybe others ??)

I received an answer in Bug 1177491 – systemd ordering cycle with nss-lookup.target
The proposed solution was to replace time-sync.target by time-set.target in named.service and this worked for me.

Regards
Philippe

17

The error message is about contradicting ordering:


erlangen:~ # journalctl -b -1 -u named.service -p notice --no-full  
-- Logs begin at Sat 2020-10-31 09:10:06 CET, end at Mon 2020-11-02 17:06:41 CET. -- 
Nov 02 16:55:41 erlangen systemd[1]: named.service: Found ordering cycle on time-sync.target/start 
Nov 02 16:55:41 erlangen systemd[1]: named.service: Found dependency on chronyd.service/start 
Nov 02 16:55:41 erlangen systemd[1]: named.service: Found dependency on nss-lookup.target/start 
Nov 02 16:55:41 erlangen systemd[1]: named.service: Found dependency on named.service/start 
Nov 02 16:55:41 erlangen systemd[1]: named.service: Job time-sync.target/start deleted to break ordering cycle starting with named.service/start 
Nov 02 16:55:42 erlangen named[1121]: starting BIND 9.16.7 (Stable Release) <id:6fd3eb7> 
Nov 02 16:55:42 erlangen named[1121]: running on Linux x86_64 5.9.1-1-default #1 SMP Mon Oct 26 07:02:23 UTC 2020 (435e92d) 
Nov 02 16:55:42 erlangen named[1121]: built with '--host=x86_64-suse-linux-gnu' '--build=x86_64-suse-linux-gnu' '--program-prefix=' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include… 
Nov 02 16:55:42 erlangen named[1121]: running as: named -t /var/lib/named -u named 
Nov 02 16:55:42 erlangen named[1121]: compiled by GCC 10.2.1 20200825 [revision c0746a1beb1ba073c7981eb09f55b3d993b32e5c] 
Nov 02 16:55:42 erlangen named[1121]: compiled with OpenSSL version: OpenSSL 1.1.1h  22 Sep 2020 
Nov 02 16:55:42 erlangen named[1121]: linked to OpenSSL version: OpenSSL 1.1.1h  22 Sep 2020 
Nov 02 16:55:42 erlangen named[1121]: compiled with libxml2 version: 2.9.10 
Nov 02 16:55:42 erlangen named[1121]: linked to libxml2 version: 20910 
Nov 02 16:55:42 erlangen named[1121]: compiled with json-c version: 0.15 
Nov 02 16:55:42 erlangen named[1121]: linked to json-c version: 0.15 
Nov 02 16:55:42 erlangen named[1121]: compiled with zlib version: 1.2.11 
Nov 02 16:55:42 erlangen named[1121]: linked to zlib version: 1.2.11 
Nov 02 16:55:42 erlangen named[1121]: ---------------------------------------------------- 
Nov 02 16:55:42 erlangen named[1121]: BIND 9 is maintained by Internet Systems Consortium, 
Nov 02 16:55:42 erlangen named[1121]: Inc. (ISC), a non-profit 501(c)(3) public-benefit 
Nov 02 16:55:42 erlangen named[1121]: corporation.  Support and training for BIND 9 are 
Nov 02 16:55:42 erlangen named[1121]: available at https://www.isc.org/support 
Nov 02 16:55:42 erlangen named[1121]: ---------------------------------------------------- 
Nov 02 16:55:42 erlangen named[1121]: adjusted limit on open files from 524288 to 1048576 
Nov 02 16:55:42 erlangen named[1121]: command channel listening on 127.0.0.1#953 
Nov 02 16:55:42 erlangen named[1121]: command channel listening on ::1#953 
Nov 02 16:55:42 erlangen named[1121]: all zones loaded 
Nov 02 16:55:42 erlangen named[1121]: running 
Nov 02 16:55:43 erlangen named[1121]: managed-keys-zone: Unable to fetch DNSKEY set '.': failure 
Nov 02 17:00:49 erlangen named[1121]: stopping command channel on 127.0.0.1#953 
Nov 02 17:00:49 erlangen named[1121]: stopping command channel on ::1#953 
Nov 02 17:00:49 erlangen named[1121]: exiting 
erlangen:~ #

Thus I made the following change:

erlangen:~ # systemd-delta -t overridden 

[OVERRIDDEN] /etc/systemd/system/named.service → /usr/lib/systemd/system/named.service

--- /usr/lib/systemd/system/named.service       2020-10-24 15:31:49.000000000 +0200
+++ /etc/systemd/system/named.service   2020-11-02 17:02:04.516731187 +0100
@@ -2,7 +2,6 @@
 Description=Berkeley Internet Name Domain (DNS)
 After=network.target
 After=time-sync.target
**-Before=nss-lookup.target**
 Wants=nss-lookup.target
 Wants=time-sync.target
 
1 overridden configuration files found.
erlangen:~ #