Hello!
I have a FreeBSD 15 system. I was able to use ntpd, but after I
installed the latest updates 15.0-RELEASE-p6, it does not start. I dunno
if that is the root cause, but after the restart I noticed the issue.
[~]$ grep -v ^# /etc/ntp.conf
tos minclock 3 maxclock 6
pool -6 2.freebsd.pool.ntp.org iburst
restrict default limited kod nomodify notrap noquery nopeer
restrict source limited kod nomodify notrap noquery
restrict 127.0.0.1
restrict ::1
leapfile "/var/db/ntpd.leap-seconds.list"
How can I diagnose the issue?
Where did you see the "got EOF" message?
What is the output of 'ntpq -p' on your machine, preferably waiting a
minute or few after ntpd starts?
On 21.04.2026 19:58 Uhr Harlan Stenn via questions Mailing List wrote:
Where did you see the "got EOF" message?
When I try to start the daemon via the service command. This executes
the startup script in FreeBSD.
[~]$ sudo service ntpd start
Starting ntpd.
daemon control: got EOF
/etc/rc.d/ntpd: WARNING: failed to start ntpd
[~]$
What is the output of 'ntpq -p' on your machine, preferably waiting a
minute or few after ntpd starts?
[ ~]$ ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
2.freebsd.pool. .POOL. 16 p - 64 0 0.000 +0.000 0.001
+basilisk.mybb.d 171.237.1.87 2 u 198 512 377 15.853 -1.130 1.459
-x1.ncomputers.o 2.34.109.103 3 u 752 1024 377 15.232 -0.881 0.319
+2003:a:47f:abe4 237.17.204.95 2 u 58 512 377 23.608 +1.292 2.623
*vps-fra1.orlean 195.145.119.188 2 u 24 512 377 9.119 +0.777 5.283
-2a01:4f8:c0c:c4 130.149.17.21 2 u 633 1024 377 18.587 -1.842 1.062
[~]$
On 4/21/2026 1:08 PM, Marco Moock wrote:
On 21.04.2026 19:58 Uhr Harlan Stenn via questions Mailing List wrote:
Where did you see the "got EOF" message?
When I try to start the daemon via the service command. This executes
the startup script in FreeBSD.
[~]$ sudo service ntpd start
Starting ntpd.
daemon control: got EOF
/etc/rc.d/ntpd: WARNING: failed to start ntpd
[~]$
That looks like an issue with FreeBSD's startup script, as the output
below from ntpq shows ntpd is running.
have a pending fix for this - that fix does not count the "pool"
directive as a "clock", right?
On Tue, Apr 21, 2026 at 20:37 UTC Harlan Stenn <stenn@nwtime.org <mailto:stenn@nwtime.org>> wrote:
On 4/21/2026 1:08 PM, Marco Moock wrote:
> On 21.04.2026 19:58 Uhr Harlan Stenn via questions Mailing List
wrote:
>
>> Where did you see the "got EOF" message?
>
> When I try to start the daemon via the service command. This executes
> the startup script in FreeBSD.
>
> [~]$ sudo service ntpd start
> Starting ntpd.
> daemon control: got EOF
> /etc/rc.d/ntpd: WARNING: failed to start ntpd
> [~]$
That looks like an issue with FreeBSD's startup script, as the output
below from ntpq shows ntpd is running.
It's hard to imagine FreeBSD suddenly got it wrong after years of
bundling ntpd, but my first step would be to investigate the command
line used to launch ntpd. It's logged at startup to syslog, or to a
file given after "logfile" in ntp.conf. EOF might indicate the script expects it to not daemonize itself, and it is. If -n/--nofork isn't on
the command line, modify the rc.d script to use it and try again.
Dave, Marco's ntp.conf file uses "minclock 3 maxclock 6". I know we
have a pending fix for this - that fix does not count the "pool"
directive as a "clock", right?
I have no such pending change. Pool lines count towards maxclock, as
they always have. NTPsec recently changed to exclude them. I'd argue a change like that belongs in ntp-dev and eventually the next major stable release, similar to the off-by-one fix that will cause noncontributing
pool & manycast associations to spin down and spur replacement.
Cheers,--
Dave Hart
On 4/21/2026 1:08 PM, Marco Moock wrote:I now ran the script using sh -x /etc/rc.d/ntpd:
On 21.04.2026 19:58 Uhr Harlan Stenn via questions Mailing List wrote:
Where did you see the "got EOF" message?
When I try to start the daemon via the service command. This executes
the startup script in FreeBSD.
[~]$ sudo service ntpd start
Starting ntpd.
daemon control: got EOF
/etc/rc.d/ntpd: WARNING: failed to start ntpd
[~]$
That looks like an issue with FreeBSD's startup script, as the output
below from ntpq shows ntpd is running.
On 4/21/2026 1:51 PM, Dave Hart wrote:Maybe append -x to the first line of /etc/rc.d/ntpd so we can see where it's going wrong?
On Tue, Apr 21, 2026 at 20:37 UTC Harlan Stenn <stenn@nwtime.org > <mailto:stenn@nwtime.org>> wrote:
On 4/21/2026 1:08 PM, Marco Moock wrote:> On 21.04.2026 19:58 Uhr Harlan Stenn via questions Mailing List
wrote:
>
>> Where did you see the "got EOF" message?
>
> When I try to start the daemon via the service command. This executes >> > the startup script in FreeBSD.
>
> [~]$ sudo service ntpd start
> Starting ntpd.
> daemon control: got EOF
> /etc/rc.d/ntpd: WARNING: failed to start ntpd
> [~]$
That looks like an issue with FreeBSD's startup script, as the output >> below from ntpq shows ntpd is running.
Maybe append -x to the first line of /etc/rc.d/ntpd so we can see where it's going wrong?
Am 22.04.26 um 12:03 schrieb Alexander Ziaee:
Maybe append -x to the first line of /etc/rc.d/ntpd so we can see where it's going wrong?
See my post from this morning:
Message-ID: <10s9f3n$3frad$1@paganini.bofh.team>
Subject: Re: ntpd does not start daemon control: got EOF
Date: Wed, 22 Apr 2026 05:25:43 +0200
--
Gruß
Marco
Junk-Mail bitte an trashcan@stinkedores.dorfdsl.de
--- Synchronet 3.21f-Linux NewsLink 1.2
Good morning, I looped in my senior colleague and am investigating now, but=
I'm not the best at debugging.
Best,
Alex
On 2026-04-22 06:37 -04:00 EDT, "Marco Moock" <mm@dorfdsl.de> wrote:
Am 22.04.26 um 12:03 schrieb Alexander Ziaee:
Maybe append -x to the first line of /etc/rc.d/ntpd so we can see where = it's going wrong?=20
See my post from this morning:
Message-ID: <10s9f3n$3frad$1@paganini.bofh.team>
=20
Subject: Re: ntpd does not start daemon control: got EOF
Date: Wed, 22 Apr 2026 05:25:43 +0200
=20
--=20
Gru=C3=9F
Marco
=20
Junk-Mail bitte an trashcan@stinkedores.dorfdsl.de
=20
=20=
Just to let everyone know, I'm virtually AFK for most of the day today. I will be back in my office tonight (west coast Canada time). I will be back full time tomorrow.
When I try to start the daemon via the service command. This executes
the startup script in FreeBSD.
Am 21.04.26 um 22:08 schrieb Marco Moock:
When I try to start the daemon via the service command. This executes
the startup script in FreeBSD.
Another thing I would like to let you know is that I have monit running
that is configured to start ntpd if it is currently not running.
Depending on which will be started first and how race conditions are
handled, this might be part of the problem.
On Wed, Apr 22, 2026 at 17:47 UTC Marco Moock <mm@dorfdsl.de> wrote:
Am 21.04.26 um 22:08 schrieb Marco Moock:
When I try to start the daemon via the service command. This executes
the startup script in FreeBSD.
Another thing I would like to let you know is that I have monit running
that is configured to start ntpd if it is currently not running.
Depending on which will be started first and how race conditions are
handled, this might be part of the problem.
That could easily be the problem. Is monit configured to use "service ntpd start"?
Am 21.04.26 um 22:08 schrieb Marco Moock:
When I try to start the daemon via the service command. This executes
the startup script in FreeBSD.
Another thing I would like to let you know is that I have monit running
that is configured to start ntpd if it is currently not running.
Depending on which will be started first and how race conditions are handled, this might be part of the problem.
Am 22.04.26 um 20:33 schrieb Dave Hart:
On Wed, Apr 22, 2026 at 17:47 UTC Marco Moock <mm@dorfdsl.de> wrote:
Am 21.04.26 um 22:08 schrieb Marco Moock:
When I try to start the daemon via the service command. This executes
the startup script in FreeBSD.
Another thing I would like to let you know is that I have monit running
that is configured to start ntpd if it is currently not running.
Depending on which will be started first and how race conditions are
handled, this might be part of the problem.
That could easily be the problem. Is monit configured to use "service
ntpd
start"?
Yes, as in case the service fails, it should start it again. Is there anything wrong with that?
Does the BSD init system use any parallel mechanisms like systemd?
On 4/22/2026 11:54 AM, Marco Moock wrote:
Am 22.04.26 um 20:33 schrieb Dave Hart:
On Wed, Apr 22, 2026 at 17:47 UTC Marco Moock <mm@dorfdsl.de> wrote:
Am 21.04.26 um 22:08 schrieb Marco Moock:
When I try to start the daemon via the service command. This executes >>>> the startup script in FreeBSD.
Another thing I would like to let you know is that I have monit running >>> that is configured to start ntpd if it is currently not running.
Depending on which will be started first and how race conditions are
handled, this might be part of the problem.
That could easily be the problem. Is monit configured to use "service >> ntpd
start"?
Yes, as in case the service fails, it should start it again. Is there anything wrong with that?
There is a potential issue of the restart process assumes a cold-start
of ntpd, as opposed to a simpler warm restart.
Does the BSD init system use any parallel mechanisms like systemd?
----
Harlan Stenn <stenn@ntp.org>
NTP Project Lead. The NTP Project is part of:
https://www.nwtime.org/ - be a member!
On 4/22/2026 10:43 AM, Marco Moock wrote:
Am 21.04.26 um 22:08 schrieb Marco Moock:
When I try to start the daemon via the service command. This executes
the startup script in FreeBSD.
Another thing I would like to let you know is that I have monit
running that is configured to start ntpd if it is currently not
running. Depending on which will be started first and how race
conditions are handled, this might be part of the problem.
Have you looked at the 'ntp-wait' script as a means to make sure ntpd is running and the clock is stable before starting a time-dependent subsystem?
Am 23.04.26 um 00:03 schrieb Harlan Stenn via questions Mailing List:
On 4/22/2026 10:43 AM, Marco Moock wrote:
Am 21.04.26 um 22:08 schrieb Marco Moock:
When I try to start the daemon via the service command. This executes
the startup script in FreeBSD.
Another thing I would like to let you know is that I have monit
running that is configured to start ntpd if it is currently not
running. Depending on which will be started first and how race
conditions are handled, this might be part of the problem.
Have you looked at the 'ntp-wait' script as a means to make sure ntpd is running and the clock is stable before starting a time-dependent subsystem?
Not yet, but for my understanding such tests belong to the start/restart operations of the service scripts. Maybe the FreeBSD people can give
more information about this.
----
Gruß
Marco
Junk-Mail bitte an trashcan@stinkedores.dorfdsl.de
In message <10sc8ha$3r263$1@paganini.bofh.team>, Marco Moock writes:
Am 23.04.26 um 00:03 schrieb Harlan Stenn via questions Mailing List:
On 4/22/2026 10:43 AM, Marco Moock wrote:Not yet, but for my understanding such tests belong to the start/restart
Am 21.04.26 um 22:08 schrieb Marco Moock:
When I try to start the daemon via the service command. This executes >>>>> the startup script in FreeBSD.
Another thing I would like to let you know is that I have monit
running that is configured to start ntpd if it is currently not
running. Depending on which will be started first and how race
conditions are handled, this might be part of the problem.
Have you looked at the 'ntp-wait' script as a means to make sure ntpd is >>> running and the clock is stable before starting a time-dependent subsystem? >>
operations of the service scripts. Maybe the FreeBSD people can give
more information about this.
I'd like to try to get a fuller understanding of the problem.
Is it correct to understand the problem began after an upgrade from FreeBSD 14 to FreeBSD 15?
Was monit also used to start ntpd on FreeBSD 14?
Is mac_ntpd in use? Was it also used on FreeBSD 14?
Am 25.04.26 um 07:23 schrieb Cy Schubert:
In message <10sc8ha$3r263$1@paganini.bofh.team>, Marco Moock writes:
Am 23.04.26 um 00:03 schrieb Harlan Stenn via questions Mailing List:
On 4/22/2026 10:43 AM, Marco Moock wrote:
Am 21.04.26 um 22:08 schrieb Marco Moock:
When I try to start the daemon via the service command. This executes >>>>> the startup script in FreeBSD.
Another thing I would like to let you know is that I have monit
running that is configured to start ntpd if it is currently not
running. Depending on which will be started first and how race
conditions are handled, this might be part of the problem.
Have you looked at the 'ntp-wait' script as a means to make sure ntpd is >>> running and the clock is stable before starting a time-dependent subsyste m?
Not yet, but for my understanding such tests belong to the start/restart >> operations of the service scripts. Maybe the FreeBSD people can give
more information about this.
I'd like to try to get a fuller understanding of the problem.
Is it correct to understand the problem began after an upgrade from FreeBSD 14 to FreeBSD 15?
I assume this was just a correlation I noticed. I do not think this is
the cause. I also only updates from 15 p5 to p6, no 14 involved.
Was monit also used to start ntpd on FreeBSD 14?
This reboot was the first after I configured ntpd.
I assume that both the init system and monit run service ntpd start at
the same time. I also have issues with sendmail in that case.
Is my assumption right that the service command does not check if
another service command ist running at the same time?
If so, I assume this is the cause of the problem.
Is mac_ntpd in use? Was it also used on FreeBSD 14?
security.mac.ntpd.uid: 123
security.mac.ntpd.enabled: 1
I haven't changed anything here.
----
Gruß
Marco
Muell und Spam bitte an abfalleimer2000@stinkedores.dorfdsl.de
The issue with ntpd is that it forks a subprocess, with a pipe between
both
processes. The child process write "R\n" to the pipe. If the parent does
not read two bytes it exits with an error. Just a guess here that monit
might have its fingers in the pipe.
On Mon, Apr 27, 2026 at 14:11=E2=80=AFUTC Cy Schubert wrote:
The issue with ntpd is that it forks a subprocess, with a pipe between
both
processes. The child process write "R\n" to the pipe. If the parent does not read two bytes it exits with an error. Just a guess here that monit might have its fingers in the pipe.
ntpd does have --nofork/-n to avoid forking to daemonize. I have not
tested, but intuitively it seems like a better solution for FreeBSD's rc.d script.
On Mon, Apr 27, 2026 at 14:11=E2=80=AFUTC Cy Schubert wrote:d
The issue with ntpd is that it forks a subprocess, with a pipe between
both
processes. The child process write "R\n" to the pipe. If the parent does
not read two bytes it exits with an error. Just a guess here that monit
might have its fingers in the pipe.
ntpd does have --nofork/-n to avoid forking to daemonize. I have not
tested, but intuitively it seems like a better solution for FreeBSD's rc.=
script.
In message <CAMbSiYD=phHqGb=DjmYoZmYOjXWvv1r+TLex=ZjiyZHfaPYBAA@mail.gmail.c
, Dave Hart writes:
On Mon, Apr 27, 2026 at 14:11=E2=80=AFUTC Cy Schubert wrote:
The issue with ntpd is that it forks a subprocess, with a pipe between
both
processes. The child process write "R\n" to the pipe. If the parent does >>> not read two bytes it exits with an error. Just a guess here that monit
might have its fingers in the pipe.
ntpd does have --nofork/-n to avoid forking to daemonize. I have not
tested, but intuitively it seems like a better solution for FreeBSD's rc.d >> script.
I suppose users of monit could use that. rcng uses the .pid file to manage services. I don't see any benefit of changing the FreeBSD rc file to
support an esoteric process monitoring application. Applications should conform to and work within the O/S, not the other way around. Though not posix pidfiles are a common UNIX-like management tool.
On 4/27/2026 12:59 PM, Cy Schubert wrote:
In message <CAMbSiYD=phHqGb=DjmYoZmYOjXWvv1r+TLex=ZjiyZHfaPYBAA@mail.gmail.c
, Dave Hart writes:
On Mon, Apr 27, 2026 at 14:11=E2=80=AFUTC Cy Schubert wrote:
The issue with ntpd is that it forks a subprocess, with a pipe between >>> both
processes. The child process write "R\n" to the pipe. If the parent does >>> not read two bytes it exits with an error. Just a guess here that monit >>> might have its fingers in the pipe.
ntpd does have --nofork/-n to avoid forking to daemonize. I have not
tested, but intuitively it seems like a better solution for FreeBSD's rc.d >> script.
I suppose users of monit could use that. rcng uses the .pid file to manage services. I don't see any benefit of changing the FreeBSD rc file to support an esoteric process monitoring application. Applications should conform to and work within the O/S, not the other way around. Though not posix pidfiles are a common UNIX-like management tool.
We believe we provide a robust mechanism for ntpd startup. If there is missing functionality here, please open a bug report.
There are a staggering number of systems out there that use a myriad of different startup schemes. Any given system can undergo spontaneous
changes in its startup framework.
It seems unreasonable to me to expect *any* application project
(including NTP) to conform to an OS.
But it *is* perfectly reasonable to expect an application project to
offer command-line and configuration options that are sufficiently
robust to allow an arbitrary OS to reliably start/stop the application.
Are we agreed on this?
----
Harlan Stenn <stenn@ntp.org>
NTP Project Lead. The NTP Project is part of:
https://www.nwtime.org/ - be a member!
In message <c125bd87-a762-4468-b214-5ead5147b82c@ntp.org>, "Harlan Stenn" write
s:
On 4/27/2026 12:59 PM, Cy Schubert wrote:
In message <CAMbSiYD=phHqGb=DjmYoZmYOjXWvv1r+TLex=ZjiyZHfaPYBAA@mail.gmail. >> c
, Dave Hart writes:
On Mon, Apr 27, 2026 at 14:11=E2=80=AFUTC Cy Schubert wrote:
The issue with ntpd is that it forks a subprocess, with a pipe between >>>>> both
processes. The child process write "R\n" to the pipe. If the parent does >>>>> not read two bytes it exits with an error. Just a guess here that monit >>>>> might have its fingers in the pipe.
ntpd does have --nofork/-n to avoid forking to daemonize. I have not
tested, but intuitively it seems like a better solution for FreeBSD's rc.d >>>> script.
I suppose users of monit could use that. rcng uses the .pid file to manage >>> services. I don't see any benefit of changing the FreeBSD rc file to
support an esoteric process monitoring application. Applications should
conform to and work within the O/S, not the other way around. Though not >>> posix pidfiles are a common UNIX-like management tool.
We believe we provide a robust mechanism for ntpd startup. If there is
missing functionality here, please open a bug report.
There are a staggering number of systems out there that use a myriad of
different startup schemes. Any given system can undergo spontaneous
changes in its startup framework.
It seems unreasonable to me to expect *any* application project
(including NTP) to conform to an OS.
But it *is* perfectly reasonable to expect an application project to
offer command-line and configuration options that are sufficiently
robust to allow an arbitrary OS to reliably start/stop the application.
Are we agreed on this?
In this regard ntp (and sendmail) are working correctly. The issue only occurs when run under monit. Monit might be inserting itself between the parent and the child in order to cause the parent not to read "R\n" on the pipe.
I have confirmed, in a jail on a 16-CURRENT system, that the problem only occurs under monit. This is why I suggested the O/P open a bugzilla bug for the problem. It's one of the following:
- a monit bug, or
- a bug uncovered by monit in the FreeBSD kernel or libc.
What ntpd is doing by opening a pipe so the child can notify the parent it can terminate itself looks reasonable.
--
Harlan Stenn <stenn@ntp.org>
NTP Project Lead. The NTP Project is part of:
https://www.nwtime.org/ - be a member!
On 4/27/2026 4:33 PM, Cy Schubert wrote:
In message <c125bd87-a762-4468-b214-5ead5147b82c@ntp.org>, "Harlan Stenn" write
s:
On 4/27/2026 12:59 PM, Cy Schubert wrote:
In message <CAMbSiYD=phHqGb=DjmYoZmYOjXWvv1r+TLex=ZjiyZHfaPYBAA@mail.gmai l.c
, Dave Hart writes:
On Mon, Apr 27, 2026 at 14:11=E2=80=AFUTC Cy Schubert wrote:
The issue with ntpd is that it forks a subprocess, with a pipe between >>>>> both
processes. The child process write "R\n" to the pipe. If the parent doe s
not read two bytes it exits with an error. Just a guess here that monit >>>>> might have its fingers in the pipe.
ntpd does have --nofork/-n to avoid forking to daemonize. I have not >>>> tested, but intuitively it seems like a better solution for FreeBSD's rc .d
script.
I suppose users of monit could use that. rcng uses the .pid file to manag e
services. I don't see any benefit of changing the FreeBSD rc file to
support an esoteric process monitoring application. Applications should >>> conform to and work within the O/S, not the other way around. Though not >>> posix pidfiles are a common UNIX-like management tool.
We believe we provide a robust mechanism for ntpd startup. If there is
missing functionality here, please open a bug report.
There are a staggering number of systems out there that use a myriad of
different startup schemes. Any given system can undergo spontaneous
changes in its startup framework.
It seems unreasonable to me to expect *any* application project
(including NTP) to conform to an OS.
But it *is* perfectly reasonable to expect an application project to
offer command-line and configuration options that are sufficiently
robust to allow an arbitrary OS to reliably start/stop the application.
Are we agreed on this?
In this regard ntp (and sendmail) are working correctly. The issue only occurs when run under monit. Monit might be inserting itself between the parent and the child in order to cause the parent not to read "R\n" on the pipe.
Cool, thanks!
I have confirmed, in a jail on a 16-CURRENT system, that the problem only occurs under monit. This is why I suggested the O/P open a bugzilla bug for the problem. It's one of the following:
- a monit bug, or
- a bug uncovered by monit in the FreeBSD kernel or libc.
What ntpd is doing by opening a pipe so the child can notify the parent it can terminate itself looks reasonable.
--
Harlan Stenn <stenn@ntp.org>
NTP Project Lead. The NTP Project is part of:
https://www.nwtime.org/ - be a member!
--
Harlan Stenn <stenn@ntp.org>
NTP Project Lead. The NTP Project is part of:
https://www.nwtime.org/ - be a member!
| Sysop: | DaiTengu |
|---|---|
| Location: | Appleton, WI |
| Users: | 1,116 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 85:26:58 |
| Calls: | 14,305 |
| Files: | 186,338 |
| D/L today: |
646 files (184M bytes) |
| Messages: | 2,525,478 |