Hi Dan,

I would recommend start both, bacula-sd and bacula-dir in debug mode and inspect what is going on by taking a deep look at the console output. You could start by only using debug mode for sd.
Use debug level -d 400. It helped me a lot since I know about this feature.

Cheers,
-fuz

Dan Langille <dan AT langille DOT org> hat am 10. Februar 2017 um 18:55 geschrieben:

On Feb 10, 2017, at 12:20 PM, Kern Sibbald <kern AT sibbald DOT com> wrote:

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.

-- 
Dan Langille - BSDCan / PGCon
dan AT langille DOT org

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users