Change:
<del> { stdenv, lib, fetchurl, openssl, perl, libcap ? null, libseccomp ? null, pps-tools }: assert stdenv.isLinux -> libcap != null; assert stdenv.isLinux -> libseccomp != null; let withSeccomp = stdenv.isLinux && (stdenv.isi686 || stdenv.isx86_64); in </del> <ins> { stdenv, lib, fetchurl, openssl, perl, pps-tools, libcap }: </ins> stdenv.mkDerivation rec { pname = "ntp";

Discussion:
ntpd is killed shortly after start. strace ends with: 950 select(23, [16 17 18 19 20 21 22], NULL, NULL, NULL) = 1 (in [19]) 950 recvmsg(19, {msgname={safamily=AFINET, sinport=htons(123), sinaddr=inetaddr("x.x.x.x")}, msgnamelen=28 =16, msgiov=[{iovbase="..."..., iovlen=2120}], msgiovlen=1, msgcontrol=[{cmsglen=32, cmsglevel=SOLSOCKET, cmsgtype=SOTIMESTAMPNSOLD, cmsgdata={tvsec=, tvnsec=}}], msgcontrollen=32, msgflags=0}, 0) = 48 950 recvmsg(19, {msgnamelen=28}, 0) = -1 EAGAIN (Resource temporarily unavailable) 950 clockadjtime(CLOCKREALTIME, <unfinished ...) = ? 950 +++ killed by SIGSYS (core dumped) +++ After adding clockadjtime to , ntpd proceeds after the call to clockadjtime(). Updated is attached. Use this config: = { enable = true; servers = [ "x.x.x.x" ]; extraFlags = [ "-g" ]; }; Do not crash. glibc changed the implementation of adjtimex to use clock_adjtime: ;a=commit;h=
There have been multiple reported regressions introduced by NTP's seccomp "support" over the years, e.g. and , now this, and several others I'm sure we're missing. While it's hilarious for me (a lazy maintainer) to say so, I'm getting a bit tired of it. Out of curiosity since this seems like a trend, I note that the patch for this original change in glibc was from 2019. Why did it take this long for this to percolate downstream, and why is there not an ntp patch for it already upstream? I did not find a historical answer to this, but I suspect no concrete one exists; it's probably a number of things leading to this. Either way, it isn't ideal for an almost 2-year old patch to suddenly be busting an extremely common daemon.

Let's also look at the seccomp filter itself: it basically enables , including some that seemingly have no reason at all for being here. You can do everything with this syscall list from write reverse-proxies to normal open/read/write/close on files. On top of that, from glancing at the , I cannot see a single security flaw that would have been mitigated by this filter in any way. But I might have missed something. Finally, didn't have much to say in support of NTPd, either. The actual award would go to chrony, which on top of that, also supports NTS (like ntpsec) and even supports features like PTP for highly accurate virtualized clocks, in addition to its normal time keeping duties being more accurate, too. My actual inclination, in light of all this, is not to add another patch to , it's to turn off seccomp support for ntpd entirely, and in the long run, deprecate and remove all alternatives in favor of chrony. Users who want to sport their own favorite-flavour NTP daemon can handle these issues on their own.
Maybe --enable-libseccomp isn't used by many. At least, CentOS, Slackware, Arch and Debian don't seem to use it. See Fine for me.
Fedora didn't have it enabled either back when they used ntp (they've switched to ntpsec)