NixOS Slow Boot Time: Chrony

Help
1

Chrony takes between 20s to a minute to load, which slows down the whole boot cycle, even with a fairly minimal chrony configuration. Is there a way to make it faster, or check ntp servers after boot?
The following systemctl status chronyd.service took 26 seconds(using systemd-analyze blame)

Oct 31 11:42:00 thegram systemd[1]: Starting chrony NTP daemon...
Oct 31 11:42:00 thegram chronyd[1478]: chronyd version 4.8 starting (+CMDMON +REFCLOCK +RTC +PRIVDROP +SCFILTER +SIGND +NTS +SECHASH +IPV6 -DEBUG)
Oct 31 11:42:10 thegram chronyd[1478]: Loaded 0 symmetric keys
Oct 31 11:42:10 thegram chronyd[1478]: Having write access to /var/lib/chrony/chrony.keys
Oct 31 11:42:10 thegram chronyd[1478]: Frequency -5.029 +/- 2.346 ppm read from /var/lib/chrony/chrony.drift
Oct 31 11:42:18 thegram chronyd[1478]: System clock off from RTC by -0.842785 seconds (slew)
Oct 31 11:42:24 thegram chronyd[1478]: System's initial offset : 0.000356 seconds slow of true (slew)
Oct 31 11:42:26 thegram systemd[1]: Started chrony NTP daemon.
Oct 31 11:42:34 thegram chronyd[1478]: Selected source 2600:1f13:eda:9800:bcd8:839c:9b40:25b2 (oregon.time.system76.com)

The nixos configuration in question

{
  config,
  lib,
  pkgs,
  ...
}:
{
  # NTP Servers
  services.chrony = {
    enable = true;
    enableNTS = true;
    servers = [
      "time.cloudflare.com"
      "paris.time.system76.com"
      "ohio.time.system76.com"
      "oregon.time.system76.com"
      "virginia.time.system76.com"
      "brazil.time.system76.com"
    ];
    extraConfig = ''
      makestep 0.1 10
    '';
    extraFlags = [
      "-s"
      "-r"
    ];
  };
}
2

The autogenerated chrony config

server time.cloudflare.com iburst nts
server paris.time.system76.com iburst nts
server ohio.time.system76.com iburst nts
server oregon.time.system76.com iburst nts
server virginia.time.system76.com iburst nts
server brazil.time.system76.com iburst nts

initstepslew 1000 time.cloudflare.com paris.time.system76.com ohio.time.system76.com oregon.time.system76.com virginia.time.system76.com brazil.time.system76.com

driftfile /var/lib/chrony/chrony.drift
keyfile /var/lib/chrony/chrony.keys
rtcfile /var/lib/chrony/chrony.rtc
ntsdumpdir /var/lib/chrony

rtcautotrim 30
rtconutc

makestep 0.1 10
3

As usual with questions stemming from systemd-analyze timings: Are you sure it’s actually delaying anything of significance? The only things that will be delayed are those listed in systemctl list-dependencies --before chronyd.service. systemd boots the parts of your system in parallel, and sure chronyd.service will delay multi-user.target from being reached, but that doesn’t matter; things are (generally) not ordered after multi-user.target, so nothing really should be delayed by it.

4

btw you could try ntpd-rs

i’m synchronizing from almost the exact same sources and i use it to run a gps time server at home

it’s been great :rofl:

5

The system displays a black screen for 20 seconds to a minute after logining in before reaching the multi-user.target and graphical.target. The time that the black screen is displayed is around the same time as the delay by chronyd. And another thing is that no other service takes anywhere near 30 seconds to load
Top 5 services by systemd-analyze blame

26.104s chronyd.service
 1.895s powertop.service
 1.518s systemd-modules-load.service
 1.246s systemd-suspend.service
 1.047s firewall.service

systemd-analyze time

Startup finished in 4.805s (firmware) + 1.333s (loader) + 7.585s (kernel) + 31.276s (userspace) = 45.001s 
graphical.target reached after 29.362s in userspace.

where the 25-30 second delay is almost all from chronyd

systemd-analyze critical-chain

graphical.target @29.362s
└─multi-user.target @29.362s
  └─chronyd.service @3.258s +26.104s
    └─network.target @3.234s
      └─wpa_supplicant.service @5.211s +28ms
        └─basic.target @2.819s
          └─dbus-broker.service @2.708s +97ms
            └─dbus.socket @2.693s +51us
              └─sysinit.target @2.453s
                └─systemd-backlight@backlight:intel_backlight.service @3.230s +35ms
                  └─system-systemd\x2dbacklight.slice @3.228s
                    └─system.slice @297ms
                      └─-.slice @297ms

which shows that chronyd isn’t delayed by any other services(the next longest service takes <100ms)

6

Ok, well like I said, the only things delayed by chrony taking a long time will be listed in systemctl list-dependencies --before chronyd.service, so what does that say? Delaying multi-user.target isn’t inherently problematic. It’s not obvious that multi-user.target taking a long time is the reason for the lengthy black screen.