Hello,
I suspect that this is a problem with the
FreeBSD networking implementation. If I
remember right on FreeBSD, when doing name
lookups, if the packet size is not *exactly*
what FreeBSD wants, it fails the call. On Linux
and other machines (Solaris, Mac), as long as
the packet size is equal or greater than what is
needed the OS call succeeds. If I am not
mistaken, Bacula allocates space for the larger
of IPv4 and IPv6 (which is always IPv6), and so
if you are using an IPv4 network, Bacula may
send OS calls with a packet size larger than
actually required.
I just spoke with a FreeBSD developer.
They are unaware of anything special in the FreeBSD
ports tree for patching FreeBSD when it comes to doing
name lookups. Specifically, gethostby*(),
getipnodeby*() just work...
If you can reproduce/encounter a situation
which fails, we will look at it and fix it. In short,
I do not think this is an issue with the FreeBSD
networking implementation.
I suspect it's a local DNS
misconfiguration on one of my hosts. Which ones, I
don't know yet. Your first post mentioned the SDs, so
I checked them. They seem OK now. I will verify them
again if I see them again.
For testing purposes, I will use dig
+short and verify that all of these FQDN resolve on
the FD, the SD, the director, and from from a fourth
host:
The FQDN of the FD (even though it is not
used in a Copy job)
The FQDN of the read SD
The FQDN of the write SD
The FQDN of the Director
I will also check that the PTR record for
the A record also resolves back to the FQDN.
If this is the case,
I would consider it a FreeBSD bug. For me to
fix it is a bit complicated, because I need to
know exactly what call is failing and the values
that FreeBSD wants. By the way, it is possible
this is already fixed in the Enterprise version
where FreeBSD is supported too. If that is the
case, in my next round of backporting to start
next week, it will get fixed.
If this was the case, I'd expect apps on FreeBSD to be
failing everywhere. They aren't. I've never patched
anything for DNS issues either.
I suspect it's more likely to be an issue on
one of the Bacula nodes in question (SD or FD) where
there is a local DNS issue.
