Bug 1218792

Summary:	pdns-recursor not starting (ordering cycle) - DNS needs time
Product:	[openSUSE] openSUSE Tumbleweed	Reporter:	Wolfgang Rosenauer <wolfgang>
Component:	Basesystem	Assignee:	Adam Majer <amajer>
Status:	CONFIRMED ---	QA Contact:	E-mail List <qa-bugs>
Severity:	Normal
Priority:	P5 - None	CC:	wolfgang
Version:	Current	Flags:	amajer: needinfo? (wolfgang)
Target Milestone:	---
Hardware:	Other
OS:	Other
Whiteboard:
Found By:	---	Services Priority:
Business Priority:		Blocker:	---
Marketing QA Status:	---	IT Deployment:	---

Description Wolfgang Rosenauer 2024-01-14 13:05:17 UTC

In current Tumbleweed there are issues starting pdns-recursor:

nss-lookup.target: Job pdns-recursor.service/start deleted to break ordering cycle starting with nss-lookup.target/start

I could imagine it is actually the very same thing as
https://bugzilla.opensuse.org/show_bug.cgi?id=1177491
?

But I'm also unsure if the very same solution should be applied or if there are other (better) ways.

Comment 1 Adam Majer 2024-02-13 09:08:31 UTC

[Unit]
Description=PowerDNS Recursor
Documentation=man:pdns_recursor(1) man:rec_control(1)
Documentation=https://doc.powerdns.com
Wants=network-online.target
After=network-online.target time-sync.target


nss-lookup.target is not listed. What is pulling it in?


systemd-analyze critical-chain time-sync.target network-online.target
The time when unit became active or started is printed after the "@" character.
The time the unit took to start is printed after the "+" character.

time-sync.target @3.560s
└─chronyd.service @3.328s +231ms
  └─nss-lookup.target @3.322s
    └─nscd.service @3.163s +153ms
      └─basic.target @3.122s
        └─sockets.target @3.122s
          └─virtstoraged-ro.socket @3.122s
            └─virtstoraged.socket @3.121s
              └─sysinit.target @3.117s
                └─auditd.service @2.981s +135ms
                  └─systemd-tmpfiles-setup.service @2.914s +65ms
                    └─systemd-journal-flush.service @1.730s +1.109s
                      └─var.mount @1.704s +12ms
                        └─local-fs-pre.target @1.639s
                          └─systemd-tmpfiles-setup-dev.service @1.476s +70ms
                            └─systemd-tmpfiles-setup-dev-early.service @1.369s +64ms
                              └─kmod-static-nodes.service @872ms +207ms
                                └─systemd-journald.socket
                                  └─system.slice
                                    └─-.slice
network-online.target @10.278s
└─systemd-networkd-wait-online.service @2.459s +7.817s
  └─systemd-networkd.service @1.706s +513ms
    └─systemd-udevd.service @1.583s +55ms
      └─systemd-tmpfiles-setup-dev.service @1.476s +70ms
        └─systemd-tmpfiles-setup-dev-early.service @1.369s +64ms
          └─kmod-static-nodes.service @872ms +207ms
            └─systemd-journald.socket
              └─system.slice
                └─-.slice

Comment 2 Adam Majer 2024-02-13 11:13:53 UTC

(In reply to Adam Majer from comment #1)
> [Unit]
> Description=PowerDNS Recursor
> Documentation=man:pdns_recursor(1) man:rec_control(1)
> Documentation=https://doc.powerdns.com
> Wants=network-online.target
> After=network-online.target time-sync.target
> 
> 
> nss-lookup.target is not listed. What is pulling it in?
> 
> 
> systemd-analyze critical-chain time-sync.target network-online.target
> The time when unit became active or started is printed after the "@"
> character.
> The time the unit took to start is printed after the "+" character.
> 
> time-sync.target @3.560s
> └─chronyd.service @3.328s +231ms
>   └─nss-lookup.target @3.322s

ok, I somehow didn't see this... but this is pulled in by time-sync.target.

It is rather important that DNS has correct time in place as otherwise it can fail with DNSSEC failures. The correct way of fixing this is for time-sync not to rely on name resolution.

Comment 3 Adam Majer 2024-02-13 11:17:50 UTC

(In reply to Adam Majer from comment #2)
> > time-sync.target @3.560s
> > └─chronyd.service @3.328s +231ms
> >   └─nss-lookup.target @3.322s


time-set.target instead of time-sync.target is what is needed here.

Comment 4 Adam Majer 2024-02-13 11:22:14 UTC

So, there was an older version of pdns-recursor that was now updated to 5.0.1 where this problem seems to have been addressed via

https://github.com/PowerDNS/pdns/pull/13210/files

Can you verify that it it works now or is it still a problem due to the time-sync.target?