Bad File Descriptor
Daniel Rudy
I'm having an issue with ntp 4.2.0-a on FreeBSD 5.4-p4 system. It
seems that ntpd is recording bad file descriptor errors in the system
log. This seems to happen every 9-10 minutes or so. I have a copy of
the logs below as well as my /etc/ntp.conf file. This has been going on
for awhile now, and I'm not sure when it started. Any idea as to what
is causing this problem?
----FILE: /var/log/messages
Aug 3 03:18:00 wildfire ntpd[933]: sendto(198.60.22.240): Bad file
descriptor
Aug 3 03:18:01 wildfire ntpd[933]: sendto(204.123.2.5): Bad file descriptor
Aug 3 03:18:01 wildfire ntpd[933]: sendto(207.46.130.100): Bad file
descriptor
Aug 3 03:18:02 wildfire ntpd[933]: sendto(198.60.22.240): Bad file
descriptor
Aug 3 03:18:02 wildfire ntpd[933]: sendto(18.72.0.3): Bad file descriptor
Aug 3 03:18:03 wildfire ntpd[933]: sendto(192.36.144.23): Bad file
descriptor
Aug 3 03:18:03 wildfire ntpd[933]: sendto(204.123.2.5): Bad file descriptor
Aug 3 03:18:03 wildfire ntpd[933]: sendto(207.46.130.100): Bad file
descriptor
Aug 3 03:18:03 wildfire ntpd[933]: sendto(209.81.9.7): Bad file descriptor
Aug 3 03:18:04 wildfire ntpd[933]: sendto(198.60.22.240): Bad file
descriptor
----FILE: /etc/ntp.conf
server time.windows.com iburst
server clepsydra.dec.com iburst
server bitsy.mit.edu iburst
server time.xmission.com iburst
server clock.via.net iburst
server clock.isc.org iburst
server ntp2.sth.netnod.se iburst
server ntp2.sp.se iburst
server us.pool.ntp.org iburst
restrict 192.168.0.0 mask 255.255.255.0 nopeer nomodify notrap kod
restrict 127.0.0.1 mask 255.0.0.0
Any help is appriciated. Thank you.
--
Daniel Rudy
Email address has been encoded to reduce spam.
Remove all numbers, then remove invalid, email, no, and spam to reply.
Eugen COCA
You may have one or maybe two servers with iburst - but you MUST have
the server administrator aproval to use it.
Make a test with no iburst option and see what's hapenning.
Please include the "ntpq -c pe" command result in your next post.
Steve Kostecke
> It makes no sense to have so many iburst options - on all time servers.
Using iburst on all your remote time servers does not hurt. In fact,
doing so is a good way to insure that you achieve the fastest possible
synchronization in the event that some your remote time servers are
unreachable.
> You may have one or maybe two servers with iburst
There is no such limit.
>- but you MUST have the server administrator aproval to use it.
Absolutely not.
You are confusing 'burst' and 'iburst'. The former multiplies the number
of packets sent by the 'client' at every poll interval; effectively
turning one client into many. The latter only multiplies the number of
packets sent during the intial synchronization.
Only 'burst' is considered unfriendly when used without permission.
> Make a test with no iburst option and see what's hapenning.
The original poster's problem is nothing to do with his use of 'iburst'.
--
Steve Kostecke <kost...@ntp.isc.org>
NTP Public Services Project - http://ntp.isc.org/
Eugen COCA
Daniel Rudy
> Sorry, I misunderstood the problem.
>
No problem, no harm done.
Anyways, I did take iburst off all servers and I still have the same
problem. Here is the output of the command that you requested:
wildfire:/etc 1035 ### ->ntpq -c pe
No association ID's returned
mike
I have not checked the code, but you appear to have a very
pesssimistic list of servers. As this is just something that appears
intermittently it may be related to the number you have defined.
Five should be enough even for the purists. Try that and see if it fixes
the issue.
Daniel Rudy
> Daniel Rudy wrote:
>
>>Hello,
>>
>> I'm having an issue with ntp 4.2.0-a on FreeBSD 5.4-p4 system. It
>>seems that ntpd is recording bad file descriptor errors in the system
>>log. This seems to happen every 9-10 minutes or so. I have a copy of
>>the logs below as well as my /etc/ntp.conf file. This has been going on
>>for awhile now, and I'm not sure when it started. Any idea as to what
>>is causing this problem?
>>
>>Any help is appriciated. Thank you.
>>
>
>
> I have not checked the code, but you appear to have a very
> pesssimistic list of servers. As this is just something that appears
> intermittently it may be related to the number you have defined.
> Five should be enough even for the purists. Try that and see if it fixes
> the issue.
New Config File:
wildfire:/etc 1033 ### ->cat ntp.conf
#server time.windows.com iburst
#server clepsydra.dec.com iburst
#server time.xmission.com iburst
#server ntp2.sth.netnod.se iburst
#server ntp2.sp.se iburst
server bitsy.mit.edu iburst
server clock.via.net iburst
server clock.isc.org iburst
server us.pool.ntp.org iburst
restrict 192.168.0.0 mask 255.255.255.0 nopeer nomodify notrap kod
restrict 127.0.0.1 mask 255.0.0.0
Aug 7 13:01:06 wildfire ntpd[8337]: sendto(209.81.9.7): Bad file descriptor
Aug 7 13:01:06 wildfire ntpd[8337]: sendto(24.130.207.189): Bad file
descriptor
Aug 7 13:01:07 wildfire ntpd[8337]: sendto(204.152.184.72): Bad file
descriptor
Aug 7 13:01:07 wildfire ntpd[8337]: sendto(18.72.0.3): Bad file descriptor
Aug 7 13:01:08 wildfire ntpd[8337]: sendto(209.81.9.7): Bad file descriptor
Aug 7 13:01:08 wildfire ntpd[8337]: sendto(24.130.207.189): Bad file
descriptor
Aug 7 13:01:09 wildfire ntpd[8337]: sendto(204.152.184.72): Bad file
descriptor
Aug 7 13:01:09 wildfire ntpd[8337]: sendto(18.72.0.3): Bad file descriptor
Aug 7 13:01:10 wildfire ntpd[8337]: sendto(209.81.9.7): Bad file descriptor
Aug 7 13:01:10 wildfire ntpd[8337]: sendto(24.130.207.189): Bad file
descriptor
Same problem with only 4 servers. And as someone else suggested, I did
remove the iburst option to no avail.
wildfire:/etc 1034 ### ->/usr/sbin/ntpd --version
/usr/sbin/ntpd: ntpd 4.2.0-a Tue Jul 19 00:50:14 PDT 2005 (1)
wildfire:/etc 1035 ### ->uname -a
FreeBSD wildfire..org 5.4-RELEASE-p4 FreeBSD 5.4-RELEASE-p4 #4: Tue Jul
19 02:29:40 PDT 2005 root@strata:/usr/obj/usr/src/sys/WILDFIRE i386
mike
albus cia...@cialug.org
Mon, 14 Mar 2005 16:57:05 -0600
found that he had 2 instances of ntpd running at the time the messages
occured. When he fixed that, the problem was corrected. Have you checked
that?
Daniel Rudy
>
> Doing some googling finds that this is not a new problem.
> albus cia...@cialug.org
> Mon, 14 Mar 2005 16:57:05 -0600
> found that he had 2 instances of ntpd running at the time the messages
> occured. When he fixed that, the problem was corrected. Have you checked
> that?
No, I didn't even consider checking that. After doing so, I found 3
instances of ntpd running. I terminated all three and restarted ntpd
and now it seems to be working properly. Now that I think about it, I
have a pretty good idea as to what happened. Thank you for your assistance.
Edrusb
The problem I met concerns ntpd when a changes in the network interface
set occurs.
My Linux system (on which runs ntpd-2.4.0) has two links to Internet:
one is permanent (except upon hardware failure), the second is a backup
modem line.
Actually the "permanent" link is broken so the dialup modem line is in
action, and a ppp0 interface goes up and down upon request. If I launch
ntpd when the link is down, ntpd will never synchronize with peers even
when the link comes back short after: it has a wildcard UDP socket
opened on port 123 and for each other interfaces that existed when ntpd
was launched, it has an UDP interface specific socket on port 123 too
(information given by the netstat command). The problem is that when the
link goes up then ntpd does not seems using the wildcard socket to try
to reach peers and does not create a new UDP interface specific socket
for this new interface (ppp0) so peers stay unreachable as reported by
ntpdc, even long after the link came back (tried more than 2 hours).
In the other way, if I launch ntpd when the link is up, it properly
exchange time information with its peers, but when the link goes down,
it keeps its UDP interface specific socket opened on ppp0 interface
while this ppp0 interface is now down. At that time I start having
"ntpd[11911]: sendto(x.x.x.x): Invalid argument"
messages as reported by syslog (with x.x.x.x rotating with all the IP
address of the configured peers). The worse thing is that when the link
comes back, ntpd still has his old socket opened, but still are reported
a lot of "Invalid Socket" messages and of course, ntpd cannot anymore
synchronize with ntp peers.
- What is the use of this wildcard UDP socket (it does not seems used)?
- Why does ntpd uses theses UDP specific interfaces sockets, while the
configuration file does not specify any interface to listen on or to not
listen on?
- How to have ntpd be able to work with a dialup link?
Any help is (very) welcome. :-)
Regards,
Denis.
--
edr...@free.fr
remove the a letter in the email above
Brad Knowles
> The problem I met concerns ntpd when a changes in the network interface
> set occurs.
When the network interface changes, you need to restart ntpd.
This is a known limitation in the current code and something that
we're hoping to get fixed soon, but this is the way it currently is.
--
Brad Knowles, <br...@stop.mail-abuse.org>
"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."
-- Benjamin Franklin (1706-1790), reply of the Pennsylvania
Assembly to the Governor, November 11, 1755
SAGE member since 1995. See <http://www.sage.org/> for more info.
_______________________________________________
questions mailing list
ques...@lists.ntp.isc.org
https://lists.ntp.isc.org/mailman/listinfo/questions
Harlan Stenn
Steve Kostecke
> The problem I met concerns ntpd when a changes in the network interface
> set occurs.
<snip>
> - How to have ntpd be able to work with a dialup link?
1. Run your ntpd (that uses remote time servers) on an a system that is
"behind" the one with the dynamic IP addresses.
or
2. Restart ntpd in your DHCP ip-change script. If you use 'iburst' on
your server lines you will acquire sync in 15-30 seconds after ntpd
restarts.
Daniel Rudy
> Dear all,
>
> The problem I met concerns ntpd when a changes in the network interface
> set occurs.
>
> My Linux system (on which runs ntpd-2.4.0) has two links to Internet:
> one is permanent (except upon hardware failure), the second is a backup
> modem line.
>
I actually ran into this problem myself. If the IP address on the
interface changes, ntpd needs to be restarted to bind to the new
address. AFAIK, the development team is working to resolve this issue.
David Woolley
> - What is the use of this wildcard UDP socket (it does not seems used)?
Handles incoming requests?
> - Why does ntpd uses theses UDP specific interfaces sockets, while the
> configuration file does not specify any interface to listen on or to not
> listen on?
I believe this is because the security features require the origin
address to be known by the sender (possibly only for servers).
> - How to have ntpd be able to work with a dialup link?
NTP is not designed for use over intermittent connections. The real
reason that this interface address problem is an issue is that some
low cost broadband suppliers deliberately mis-operate DHCP to make
their customers' IP addresses unstable and prevent them running servers
on home user accounts.
What I do with intermittent connections is to trim out the static
component of the frequency error using ntptime and tickadj and then
occassionally re-correct the phase using ntpdate, making sure that I
do it when the line is idle.
> Any help is (very) welcome. :-)
As noted elsewhere, you can do IP address masquerading down stream so that
ntpd sees a fixed address.
Edrusb
> In article <hmvidd...@barnabe.home.fr>, Edrusb <edr...@free.fr> wrote:
>
>
>>- What is the use of this wildcard UDP socket (it does not seems used)?
>
>
> Handles incoming requests?
Yes probably, it is too bad the same socket has not been used to send
data too, just leting the system put the appropriate Source IP and
select the adequate output interface according to system's routing
decision. This way there would not have any need to scan available
network interfaces for changes.
>>- Why does ntpd uses theses UDP specific interfaces sockets, while the
>>configuration file does not specify any interface to listen on or to not
>>listen on?
>
>
> I believe this is because the security features require the origin
> address to be known by the sender (possibly only for servers).
the outgoing IP packets have their IP source field set by the system in
any way I guess, even when sending from a wildcard socket.
>
[...]
>
>>Any help is (very) welcome. :-)
>
>
> As noted elsewhere, you can do IP address masquerading down stream so that
> ntpd sees a fixed address.
Thanks for the idea, but public servers still have static IP address :-)
masquerading them would not help :-/
I have a "tap" interfaces that handles the traffic when the link is down
for dial on demand (see "diald" interesting and powerful program),
unfortunately, ntpd does not bind a socket to this interface! Too bad.
I guess, the best solution waiting for next ntpd release, as described
by Steve Kostecke, is to have my local ntpd server for my local network
be "inside" the network without any dynamic IP address.
Thansk to all,
Cheers,
Denis.
Brad Knowles
> Yes probably, it is too bad the same socket has not been used to send
> data too, just leting the system put the appropriate Source IP and
> select the adequate output interface according to system's routing
> decision. This way there would not have any need to scan available
> network interfaces for changes.
Nice theory, but it doesn't work that way in practice. Dig deep
into the code of programs like ntpd, BIND, and sendmail if you want
to understand why, but be prepared to spend a significant amount of
time learning about cross-platform issues, problems with IPv4 versus
IPv6, guaranteeing that reply packets always come from the same
interface and IP address that the query was sent to, and a whole host
of other problems.
It's just not that simple.
> I have a "tap" interfaces that handles the traffic when the link is
> down for dial on demand (see "diald" interesting and powerful
> program), unfortunately, ntpd does not bind a socket to this
> interface! Too bad.
Well, ntpd should bind to all interfaces that are up at the time
it starts, and remain bound to them until it is restarted. So, if
that tap interface works at all times, and remains consistent at all
times, you shouldn't have any problems.
> I guess, the best solution waiting for next ntpd release, as described
> by Steve Kostecke, is to have my local ntpd server for my local network
> be "inside" the network without any dynamic IP address.
Either that, or stopping and restarting ntpd every time the
dynamic IP address changes.
David Woolley
> the outgoing IP packets have their IP source field set by the system in
> any way I guess, even when sending from a wildcard socket.
But too late to be included in the message authentication code, so the
packets will have an invalid authentication code and will be rejected
by an authenticating client.
> Thanks for the idea, but public servers still have static IP address :-)
> masquerading them would not help :-/
It is the client address that will be masqueraded.
> I guess, the best solution waiting for next ntpd release, as described
> by Steve Kostecke, is to have my local ntpd server for my local network
> be "inside" the network without any dynamic IP address.
Note that I believe that the proposed solution is to either periodically
scan for new interfaces or to scan when a server fails.
Brad Knowles
>> I guess, the best solution waiting for next ntpd release, as described
>> by Steve Kostecke, is to have my local ntpd server for my local network
>> be "inside" the network without any dynamic IP address.
>
> Note that I believe that the proposed solution is to either periodically
> scan for new interfaces or to scan when a server fails.
Personally, I think you probably need to do both. You need to
periodically rescan the interfaces, in case a new interface has been
added but no old ones have gone away, and you need to also detect
when old ones have disappeared.
Danny Mayer
See bug #51. Yes, as Brad says, we will be fixing this, but it's not a
simple thing to implement so it won't be soon.
Danny
>
> Any help is (very) welcome. :-)
>
>
> Regards,
> Denis.
>
> --
> edr...@free.fr
> remove the a letter in the email above
_______________________________________________
Edrusb
> At 12:18 PM +0200 2005-08-13, Edrusb wrote:
>
>> Yes probably, it is too bad the same socket has not been used to send
>> data too, just leting the system put the appropriate Source IP and
>> select the adequate output interface according to system's routing
>> decision. This way there would not have any need to scan available
>> network interfaces for changes.
>
>
> Nice theory, but it doesn't work that way in practice. Dig deep
> into the code of programs like ntpd, BIND, and sendmail if you want to
> understand why, but be prepared to spend a significant amount of time
> learning about cross-platform issues, problems with IPv4 versus IPv6,
> guaranteeing that reply packets always come from the same interface and
> IP address that the query was sent to, and a whole host of other problems.
>
> It's just not that simple.
:-)))
Yes, you are right, it is easy to find things simple when you are far
away from the problem... Anyway, don't imagine I said or even thought
ntpd was bad designed or something like that, I really appreciate this
nice and useful program!
Thank you for your clear answers.
> [...]
Best Regards,
Denis.
--
Edrusb
Danny Mayer
> David Woolley wrote:
>
>> In article <hmvidd...@barnabe.home.fr>, Edrusb <edr...@free.fr>
>> wrote:
>>
>>
>>> - What is the use of this wildcard UDP socket (it does not seems used)?
>>
>>
>>
>> Handles incoming requests?
>
The wildcard addresses are not used for anything except to prevent other
applications grabbing the addresses and ports.
>
> Yes probably, it is too bad the same socket has not been used to send
> data too, just leting the system put the appropriate Source IP and
> select the adequate output interface according to system's routing
> decision. This way there would not have any need to scan available
> network interfaces for changes.
>
No, we need to send out responses with the correct IP address to ensure
that it can be authenticated. You cannot do this with the wildcard port
as you have no control over the address it will used.
> >>- Why does ntpd uses theses UDP specific interfaces sockets, while the
> >>configuration file does not specify any interface to listen on or to not
> >>listen on?
> >
> >
> > I believe this is because the security features require the origin
> > address to be known by the sender (possibly only for servers).
>
> the outgoing IP packets have their IP source field set by the system in
> any way I guess, even when sending from a wildcard socket.
>
No. If you send from the wildcard port the system will choose which
address to use. We need to control that. If you send a request to
address A and got a response from address B, it will be assumed to be an
invalid response to the request to address A.
Danny
>
>>
> [...]
>
>>
>>> Any help is (very) welcome. :-)
>>
>>
>>
>> As noted elsewhere, you can do IP address masquerading down stream so
>> that
>> ntpd sees a fixed address.
>
>
> Thanks for the idea, but public servers still have static IP address :-)
> masquerading them would not help :-/
>
No, it's your server that is being protected from changes not the public
servers.
Danny
Edrusb
> At 8:55 PM +0100 2005-08-13, David Woolley wrote:
>
>>> I guess, the best solution waiting for next ntpd release, as described
>>> by Steve Kostecke, is to have my local ntpd server for my local network
>>> be "inside" the network without any dynamic IP address.
>>
>>
>> Note that I believe that the proposed solution is to either periodically
>> scan for new interfaces or to scan when a server fails.
>
>
> Personally, I think you probably need to do both. You need to
> periodically rescan the interfaces, in case a new interface has been
> added but no old ones have gone away, and you need to also detect when
> old ones have disappeared.
>
Detecting when an old interface has "disappeared" should be possible
looking at the errno global variable when sendto() system call returns
an error (errno = EINVAL). And I guess, like Bind does, a periodic
interface scanning plus an "on event" scanning (when sendto() returns an
error) should be "large" enough to address this problem?
Regards,
Denis.
Tom Einertson
"Edrusb" <edr...@free.fr> wrote in message
news:mquqdd...@barnabe.home.fr...
> Detecting when an old interface has "disappeared" should be possible
> looking at the errno global variable when sendto() system call returns
> an error (errno = EINVAL). And I guess, like Bind does, a periodic
> interface scanning plus an "on event" scanning (when sendto() returns an
> error) should be "large" enough to address this problem?
>
> Regards,
> Denis.
Checking errno might be one way to detect when an interface has disappeared.
Assuming that you already have code to read up the list of interfaces on a
server, another simple approach is to run that code again and then compare
the current interface list to what NTP was using previously.
You have no need to know
20:48:43 +0000 said:
> At 10:09 PM +0200 2005-08-12, Edrusb wrote:
>
>> The problem I met concerns ntpd when a changes in the network interface
>> set occurs.
>
> When the network interface changes, you need to restart ntpd.
> This is a known limitation in the current code and something that
> we're hoping to get fixed soon, but this is the way it currently is.
You don't have to restart. You can use some scripting and ntpdc to remove
and readd any servers which have become unreachable. This has been
explained here several times in the past.
--
Avoid reality at all costs.
$email =~ s/n(.)a(.)n(.)a(.)e(.+)invalid/$1$2$3$4$5au/;
icbm: 33.43.46S 150.59.27E
Brad Knowles
>> When the network interface changes, you need to restart ntpd.
>> This is a known limitation in the current code and something that
>> we're hoping to get fixed soon, but this is the way it currently is.
>
> You don't have to restart. You can use some scripting and ntpdc to remove
> and readd any servers which have become unreachable. This has been
> explained here several times in the past.
That doesn't work when the interface IP address changes, because
the current code doesn't watch for interface changes, drop old
interfaces from the list, add new ones as they come along, etc....
With the current code, your solution will only work when the
interface keeps the same IP address, and your connectivity is only
interrupted. If you're behind a NAT/router which gets its IP address
changed but your local hosts keep theirs, you might still have
issues. Certainly, you'll be likely to have to drop and re-add.
As I said, we're working on fixing this.