Bug 1218792 - pdns-recursor not starting (ordering cycle) - DNS needs time
Summary: pdns-recursor not starting (ordering cycle) - DNS needs time
Status: CONFIRMED
Alias: None
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Basesystem (show other bugs)
Version: Current
Hardware: Other Other
: P5 - None : Normal (vote)
Target Milestone: ---
Assignee: Adam Majer
QA Contact: E-mail List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2024-01-14 13:05 UTC by Wolfgang Rosenauer
Modified: 2024-02-13 11:22 UTC (History)
1 user (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---
amajer: needinfo? (wolfgang)


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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?