Menu
▾
▴
Re: [Bacula-users] Bacula 7 on FreeBSD, suddenly can't do anything
|
From: dweimer <dw...@dw...> - 2015-01-28 16:48:41
|
On 01/28/2015 9:09 am, Cejka Rudolf wrote: > dweimer wrote (2015/01/27): >> ... > > Interesting. What did you do right before "suddenly" actually? > Nothing, or something and somewhere? :o) > >> > It had me scratching my head for a while, because it was still half >> > working. My nagios and bacula daemons couldn't find any *.local names >> > anymore, but I could still ping the same machines by name at the >> > command prompt. > > It seems that you have some nontrivial DNS configuration? Some local > daemon like named or unbound? Could you show us some example? > > ping some.server # what ip is used here? what says tcpdump port domain? > grep some.server /etc/hosts # or is the translation from hosts? > grep hosts /etc/nsswitch.conf # do you have "hosts: files dns" here? > cat /etc/resolv.conf # something suspicious here? > ldd -a /usr/local/bin/bacula-dir | grep libc.so # just /lib/libc.so.7 > here? > file /usr/local/bin/bacula-dir # for which FreeBSD is it compiled? > > Ping uses gethostbyname2(). Bacula uses getaddrinfo(), if there is > #define HAVE_GETADDRINFO 1 in src/config.h. So ping and bacula could > behave differently, but it is weird. Unfortunately, nslookup and host > use different mechanisms. They skip /etc/hosts for example. So they > can check remote DNS server, but not problems with local translation, > which seems to be your case. > >> Yes to .local DNS suffix, ... > > And please how? > >> morning ran without a hitch. Then Monday night when I went to login >> after switching my external hard drive for the new week that's when >> the >> problems were noticeable. At first it connected, just horribly slow. >> After a restart of all the Bacula services, I could no longer connect >> with bconsole on the local machine. > > Could you do gdb bconsole and check, that timeout is with name > resolution? > > And looking into bacula-7.0.5 sources, I think that debug level 100 > and tracing on should be sufficient for tracing name resolution > (src/lib/bsock.c and BSOCK::open, then bnet_host2ipaddrs and > resolv_host > in bnet.c). > > -- > Rudolf Cejka <cejkar at fit.vutbr.cz> http://www.fit.vutbr.cz/~cejkar > Brno University of Technology, Faculty of Information Technology > Bozetechova 2, 612 66 Brno, Czech Republic > > ------------------------------------------------------------------------------ > Dive into the World of Parallel Programming. The Go Parallel Website, > sponsored by Intel and developed in partnership with Slashdot Media, is > your > hub for all things parallel software development, from weekly thought > leadership blogs to news, videos, case studies, tutorials and more. > Take a > look and join the conversation now. http://goparallel.sourceforge.net/ > _______________________________________________ > Bacula-users mailing list > Bac...@li... > https://lists.sourceforge.net/lists/listinfo/bacula-users root@bacula:/ # cat /etc/nsswitch.conf # # nsswitch.conf(5) - name service switch configuration file # $FreeBSD: releng/10.0/etc/nsswitch.conf 224765 2011-08-10 20:52:02Z dougb $ # #group: compat group: files ldap group_compat: nis hosts: files dns networks: files #passwd: compat passwd: files ldap passwd_compat: nis shells: files services: compat services_compat: nis protocols: files rpc: files root@bacula:/ # cat /etc/resolv.conf # Generated by resolvconf search dweimer.local. nameserver 192.168.5.1 root@bacula:/ # nslookup bacula.dweimer.local Server: 192.168.5.1 Address: 192.168.5.1#53 Name: bacula.dweimer.local Address: 192.168.5.4 root@bacula:/ # host bacula.dweimer.local bacula.dweimer.local has address 192.168.5.4 host file is default, only has the default local host entries. root@bacula:/ # cat /etc/hosts | grep -v "^#" ::1 localhost localhost.my.domain 127.0.0.1 localhost localhost.my.domain It isn't just this one hostname that is failing, it was also the resolution to the clients. In this case workstation.dweimer.local (My Windows 8.1 PC) and freebsd.dweimer.local (the webserver where webacula is installed). The nslookup and host commands resolve them properly as well. When I finish the FreeBSD 10.1-RELEASE-p5 updates today I will search the full file system (not including the backup volumes) for any references to 192.168.1. Nothing else is having issues on the network. I would say only Bacula has the problem on this server, but since Bacula is the only thing on the server. If I don't find anything on the system I will hit up the FreeBSD mailing list again. as it appears to be something specific on my system. no local named daemon is running or installed, only have user land bind utilities like nslookup and such available. There is the default unbound installed as part of the OS. So maybe its something strange in it, it's running under its default configuration/options. I haven't even had a chance to learn where you set any options in it. Its definitely something specific to this machine as the web server is running the same FreeBSD version, same network setup and bconsole resolves bacula.dweimer.local fine from it. -- Thanks, Dean E. Weimer http://www.dweimer.net/ |