[S] Why do hostname and sendmail steps at boot take so long?

The is for [SOLVED]

There are a few steps in the boot process of my FreeBSD 10.0-RELEASE installation that take what seems to be an excessive amount of time. Namely, these are:

Code:
Setting hostname: hostname.local
...
Starting sendmail_submit
Starting sendmail_msp_queue

I don't even remember the sendmail lines from previous versions of FreeBSD. Are they necessary? Is there a way to speed them up?

This is on a VirtualBox guest install of FreeBSD 10.0-RELEASE amd64.
 
Re: Why do some steps at boot take so long?

#1: The Interrupted Unix FAQ.

If you see things that take twenty or thirty seconds instead of being nearly instant, think DNS. Does that machine's hostname resolve to an address?
 
Re: Why do some steps at boot take so long?

Since I don't own any domains, I just set the hostname to vbsd.local. Is that incorrect form, i.e., should I have called it vbsd.example.org or something similar?

I just checked /etc/resolv.conf and it has the correct information (same as what OS X displays):
Code:
# Generated by resolvconf
search gateway.2wire.net
nameserver 192.168.1.254

(I have a 2WIRE router provided by my ISP.)

During installation, I chose to use DHCP and the network connection seemed to work fine afterwards. VirtualBox is using NAT for my FreeBSD VM.
 
Re: Why do some steps at boot take so long?

So how long does it take to do an nslookup vbsd.local on that machine?
 
Re: Why do some steps at boot take so long?

Code:
nslookup: Command not found

I believe nslookup was removed from the base system in FreeBSD 10. Is there an alternative?
 
Re: Why do some steps at boot take so long?

Drill took about a second to produce the following output:

# drill vbsd.local
Code:
;; ->>HEADER<<- opcode: QUERY, rcode: NXDOMAIN, id: 16280
;; flags: qr rd ra ; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;; vbsd.local.  IN     A

;; ANSWER SECTION:

;; AUTHORITY SETION:
	3092	IN		SOA		a.root-servers.net. nstld.verisign-grs.com. 2014020801 1800 900 604800 86400

;; ADDITIONAL SECTION:

;; Query time: 1034 msec
;; SERVER: 192.168.1.254
;; WHEN: Sat Feb  8 18:27:23 2014
;; MSG SIZE  rcvd: 103

Host took a few seconds and did not find anything:

# host vbsd.local
Code:
Host vbsd.local not found: 3(NXDOMAIN)
 
Re: Why do some steps at boot take so long?

Any hostname you set will not be found in the ISP's DNS. For dynamic machines, people often add the hostname to /etc/hosts.
 
Re: Why do some steps at boot take so long?

Does that mean I should add vbsd.local to my /etc/hosts? This is my current /etc/hosts. I believe it's just the default since I have never edited it manually:

Code:
# $FreeBSD: release/10.0.0/etc/hosts 109997 2003-01-28 21:29:23Z dbaker $
#
# Host Database
#
# This file should contain the addresses and aliases for local hosts that
# share this file.  Replace 'my.domain' below with the domainname of your
# machine.
#
# In the presence of the domain name service or NIS, this file may
# not be consulted at all; see /etc/nsswitch.conf for the resolution order.
#
#
::1			localhost localhost.my.domain
127.0.0.1		localhost localhost.my.domain
#
# Imaginary network.
#10.0.0.2		myname.my.domain myname
#10.0.0.3		myfriend.my.domain myfriend
#
# According to RFC 1918, you can use the following IP networks for
# private nets which will never be connected to the Internet:
#
#	10.0.0.0	-   10.255.255.255
#	172.16.0.0	-   172.31.255.255
#	192.168.0.0	-   192.168.255.255
#
# In case you want to be able to connect to the Internet, you need
# real official assigned numbers.  Do not try to invent your own network
# numbers but instead get one from your network provider (if any) or
# from your regional registry (ARIN, APNIC, LACNIC, RIPE NCC, or AfriNIC.)
#
 
Re: Why do some steps at boot take so long?

I just added that line to /etc/hosts and those three steps still take a long time. Specifically,

Code:
Setting hostname: vbsd.local (12 seconds)
Starting sendmail_submit (16 seconds)
Starting sendmail_msp_queue (16 seconds)

Everything else in the boot process is pretty much instant.
 
Re: Why do some steps at boot take so long?

lionoceros said:
I just added that line to /etc/hosts and those three steps still take a long time. Specifically,

Code:
Setting hostname: vbsd.local (12 seconds)
Starting sendmail_submit (16 seconds)
Starting sendmail_msp_queue (16 seconds)

Everything else in the boot process is pretty much instant.

Dumb question: What does the disk activity light do during this time? If it is on continuously, or blinking madly, these commands for some reason are doing a lot of disk I/O. Which makes little sense, but I've seen pigs fly, and it is easy to check.

I'm also betting that the problem is some timeout in name resolution, but don't know how to offer concrete help on fixing it.

The next step is going to be pretty ugly. Go into /etc/rc* and /etc/rc.d/*, and find out exactly which scripts are executing these steps. For example, the first one is done by /etc/rc.d/hostname, and the only interesting command in there is /bin/hostname "${hostname}". Then change that command to be truss -d /bin/hostname "${hostname}" 2> /tmp/hostname.truss. This means: run the hostname command with tracing of all system calls, with the time of each trace, and save the output in a file in /tmp. If you can't tell which command in the script takes a lot of time, then just add date statements between the commands, and see which one runs long. Reboot your machine, and study the output, to see which system call took forever, or which system calls needed to be done so often that it took a long time. Note: this is real work, and you probably have to do this several times in a row.
 
Re: Why do some steps at boot take so long?

It looks like there's very little disk activity during those steps.

I changed the /bin/hostname command as you instructed. This is the output of /tmp/hostname.truss:

Code:
0.002034895 mmap(0x0,32768,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 34366136320 (0x80061a000)
0.003084191 issetugid(0x800819f30,0x7fffffffefd2,0x40,0x0,0xffff80080081af5e,0x0) = 0 (0x0)
0.004334070 lstat("/etc",{ mode=drwxr-xr-x ,inode=2568192,size=2048,blksize=32768 }) = 0 (0x0)
0.005242286 lstat("/etc/libmap.conf",{ mode=-rw-r--r-- ,inode=2568273,size=112,blksize=32768 }) = 0 (0x0)
0.006214756 open("/etc/libmap.conf",O_CLOEXEC,01760) = 3 (0x3)
0.007134147 fstat(3,{ mode=-rw-r--r-- ,inode=2568273,size=112,blksize=32768 }) = 0 (0x0)
0.007887874 mmap(0x0,112,PROT_READ,MAP_PRIVATE,3,0x0) = 34366169088 (0x800622000)
0.008750833 close(3)				 = 0 (0x0)
0.009816052 lstat("/usr",{ mode=drwxr-xr-x ,inode=1203840,size=512,blksize=32768 }) = 0 (0x0)
0.010780141 lstat("/usr/local",{ mode=drwxr-xr-x ,inode=1203851,size=512,blksize=32768 }) = 0 (0x0)
0.011653436 lstat("/usr/local/etc",{ mode=drwxr-xr-x ,inode=1306825,size=1024,blksize=32768 }) = 0 (0x0)
0.012721729 lstat("/usr/local/etc/libmap.d",0x7fffffffb918) ERR#2 'No such file or directory'
0.021211076 munmap(0x800622000,112)		 = 0 (0x0)
0.021694377 open("/var/run/ld-elf.so.hints",O_CLOEXEC,00) ERR#2 'No such file or directory'
0.022308981 access("/lib/libc.so.7",0)		 = 0 (0x0)
0.022800942 open("/lib/libc.so.7",O_CLOEXEC,030363770) = 3 (0x3)
0.023230048 fstat(3,{ mode=-r--r--r-- ,inode=2166925,size=1567216,blksize=32768 }) = 0 (0x0)
0.023614454 mmap(0x0,4096,PROT_READ,MAP_PRIVATE|MAP_PREFAULT_READ,3,0x0) = 34366169088 (0x800622000)
0.024063114 mmap(0x0,3772416,PROT_NONE,MAP_PRIVATE|MAP_ANON|MAP_NOCORE,-1,0x0) = 34368237568 (0x80081b000)
0.024529375 mmap(0x80081b000,1458176,PROT_READ|PROT_EXEC,MAP_PRIVATE|MAP_FIXED|MAP_NOCORE|MAP_PREFAULT_READ,3,0x0) = 34368237568 (0x80081b000)
0.025023851 mmap(0x800b7f000,49152,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED|MAP_PREFAULT_READ,3,0x164000) = 34371792896 (0x800b7f000)
0.025541235 mmap(0x800b8b000,167936,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED|MAP_ANON,-1,0x0) = 34371842048 (0x800b8b000)
0.026044372 munmap(0x800622000,4096)		 = 0 (0x0)
0.026562594 close(3)				 = 0 (0x0)
0.027126353 mmap(0x0,102400,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 34366169088 (0x800622000)
0.027735369 sysarch(0x81,0x7fffffffd308,0x4,0x0,0xffffffffffaa2080,0xf0000000) = 0 (0x0)
0.028202746 sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) = 0 (0x0)
0.028633807 sigprocmask(SIG_SETMASK,0x0,0x0)	 = 0 (0x0)
0.029028270 readlink("/etc/malloc.conf",0x7fffffffca30,1024) ERR#2 'No such file or directory'
0.029351496 issetugid(0x80095693e,0x7fffffffca30,0xffffffffffffffff,0x0,0x3a,0xffffffff0fffffff) = 0 (0x0)
0.029713832 mmap(0x0,4194304,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 34372009984 (0x800bb4000)
0.030059686 munmap(0x800bb4000,4194304)		 = 0 (0x0)
0.030444093 mmap(0x0,8384512,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 34372009984 (0x800bb4000)
0.030865375 munmap(0x800bb4000,311296)		 = 0 (0x0)
0.031177147 munmap(0x801000000,3878912)		 = 0 (0x0)
0.032266671 sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) = 0 (0x0)
0.032860880 sigprocmask(SIG_SETMASK,0x0,0x0)	 = 0 (0x0)
0.033513198 sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) = 0 (0x0)
0.033903471 sigprocmask(SIG_SETMASK,0x0,0x0)	 = 0 (0x0)
0.034252957 __sysctl(0x7fffffffdbc8,0x2,0x0,0x0,0x7fffffffdf2e,0xa) = 0 (0x0)
0.034643509 sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) = 0 (0x0)
0.034972881 sigprocmask(SIG_SETMASK,0x0,0x0)	 = 0 (0x0)
0.035336614 sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) = 0 (0x0)
0.035671573 sigprocmask(SIG_SETMASK,0x0,0x0)	 = 0 (0x0)
0.036039497 sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) = 0 (0x0)
0.036382836 sigprocmask(SIG_SETMASK,0x0,0x0)	 = 0 (0x0)
0.036382836 process exit, rval = 0

I'm not sure what information this gives me or if it provides any clues as to what could be delaying the hostname and sendmail commands.
 
Re: Why do some steps at boot take so long?

Look at /var/log/maillog. Sendmail looks for an FQDN, so just the hostname is probably not enough. Based on the resolv.conf, it might be looking for vbsd.local.gateway.2wire.net or vbsd.local.2wire.net.
 
Re: Why do hostname and sendmail steps at boot take so long?

Looks like gethostbyaddr keeps failing:

Code:
Feb  7 18:44:19 vbsd newsyslog[651]: logfile first created
Feb  7 18:45:16 vbsd sm-mta[816]: gethostbyaddr(10.0.2.15) failed: 1
Feb  7 18:45:16 vbsd sm-mta[817]: starting daemon (8.14.7): SMTP+queueing@00:30:00
Feb  7 18:45:16 vbsd sm-mta[817]: STARTTLS=server: file /etc/mail/certs/dh.param unsafe: No such file or directory
Feb  7 18:46:03 vbsd sm-msp-queue[820]: starting daemon (8.14.7): queueing@00:30:00
Feb  7 19:10:11 vbsd sm-mta[792]: gethostbyaddr(10.0.2.15) failed: 1
Feb  7 19:10:11 vbsd sm-mta[793]: starting daemon (8.14.7): SMTP+queueing@00:30:00
Feb  7 19:10:11 vbsd sm-mta[793]: STARTTLS=server: file /etc/mail/certs/dh.param unsafe: No such file or directory
Feb  7 19:11:00 vbsd sm-msp-queue[796]: starting daemon (8.14.7): queueing@00:30:00
Feb  7 19:56:18 vbsd sm-mta[806]: gethostbyaddr(10.0.2.15) failed: 1
Feb  7 19:56:18 vbsd sm-mta[807]: starting daemon (8.14.7): SMTP+queueing@00:30:00
Feb  7 19:56:18 vbsd sm-mta[807]: STARTTLS=server: file /etc/mail/certs/dh.param unsafe: No such file or directory
Feb  7 19:57:08 vbsd sm-msp-queue[810]: starting daemon (8.14.7): queueing@00:30:00
Feb  7 20:40:09 vbsd sm-mta[804]: gethostbyaddr(10.0.2.15) failed: 1
Feb  7 20:40:09 vbsd sm-mta[805]: starting daemon (8.14.7): SMTP+queueing@00:30:00
Feb  7 20:40:09 vbsd sm-mta[805]: STARTTLS=server: file /etc/mail/certs/dh.param unsafe: No such file or directory
Feb  7 20:40:59 vbsd sm-msp-queue[808]: starting daemon (8.14.7): queueing@00:30:00
Feb  7 23:33:30 vbsd sm-mta[810]: gethostbyaddr(10.0.2.15) failed: 1
Feb  7 23:33:30 vbsd sm-mta[811]: starting daemon (8.14.7): SMTP+queueing@00:30:00
Feb  7 23:33:30 vbsd sm-mta[811]: STARTTLS=server: file /etc/mail/certs/dh.param unsafe: No such file or directory
Feb  7 23:34:19 vbsd sm-msp-queue[814]: starting daemon (8.14.7): queueing@00:30:00
Feb  7 23:37:21 vbsd sm-mta[801]: gethostbyaddr(10.0.2.15) failed: 1
Feb  7 23:37:21 vbsd sm-mta[802]: starting daemon (8.14.7): SMTP+queueing@00:30:00
Feb  7 23:37:21 vbsd sm-mta[802]: STARTTLS=server: file /etc/mail/certs/dh.param unsafe: No such file or directory
Feb  7 23:38:10 vbsd sm-msp-queue[805]: starting daemon (8.14.7): queueing@00:30:00
Feb  8 16:19:48 vbsd sm-mta[858]: gethostbyaddr(10.0.2.15) failed: 1
Feb  8 16:19:48 vbsd sm-mta[1098]: starting daemon (8.14.7): SMTP+queueing@00:30:00
Feb  8 16:19:48 vbsd sm-mta[1098]: STARTTLS=server: file /etc/mail/certs/dh.param unsafe: No such file or directory
Feb  8 16:20:37 vbsd sm-msp-queue[1188]: starting daemon (8.14.7): queueing@00:30:00
Feb  8 16:33:34 vbsd sm-mta[852]: gethostbyaddr(10.0.2.15) failed: 1
Feb  8 16:33:34 vbsd sm-mta[1088]: starting daemon (8.14.7): SMTP+queueing@00:30:00
Feb  8 16:33:34 vbsd sm-mta[1088]: STARTTLS=server: file /etc/mail/certs/dh.param unsafe: No such file or directory
Feb  8 16:34:23 vbsd sm-msp-queue[1181]: starting daemon (8.14.7): queueing@00:30:00
Feb  8 16:40:52 vbsd sm-mta[850]: gethostbyaddr(10.0.2.15) failed: 1
Feb  8 16:40:52 vbsd sm-mta[1086]: starting daemon (8.14.7): SMTP+queueing@00:30:00
Feb  8 16:40:52 vbsd sm-mta[1086]: STARTTLS=server: file /etc/mail/certs/dh.param unsafe: No such file or directory
Feb  8 16:41:41 vbsd sm-msp-queue[1180]: starting daemon (8.14.7): queueing@00:30:00
Feb  8 17:03:41 vbsd sm-mta[856]: gethostbyaddr(10.0.2.15) failed: 1
Feb  8 17:03:41 vbsd sm-mta[1092]: starting daemon (8.14.7): SMTP+queueing@00:30:00
Feb  8 17:03:41 vbsd sm-mta[1092]: STARTTLS=server: file /etc/mail/certs/dh.param unsafe: No such file or directory
Feb  8 17:04:30 vbsd sm-msp-queue[1185]: starting daemon (8.14.7): queueing@00:30:00
Feb  8 18:43:38 vbsd sm-mta[856]: gethostbyaddr(10.0.2.15) failed: 1
Feb  8 18:43:38 vbsd sm-mta[937]: starting daemon (8.14.7): SMTP+queueing@00:30:00
Feb  8 18:43:38 vbsd sm-mta[937]: STARTTLS=server: file /etc/mail/certs/dh.param unsafe: No such file or directory
Feb  8 18:43:55 vbsd sm-msp-queue[1020]: starting daemon (8.14.7): queueing@00:30:00
Feb  8 18:51:10 vbsd sm-mta[852]: gethostbyaddr(10.0.2.15) failed: 1
Feb  8 18:51:10 vbsd sm-mta[938]: starting daemon (8.14.7): SMTP+queueing@00:30:00
Feb  8 18:51:10 vbsd sm-mta[938]: STARTTLS=server: file /etc/mail/certs/dh.param unsafe: No such file or directory
Feb  8 18:51:27 vbsd sm-msp-queue[1016]: starting daemon (8.14.7): queueing@00:30:00
Feb  9 09:44:46 vbsd sm-mta[857]: gethostbyaddr(10.0.2.15) failed: 1
Feb  9 09:44:46 vbsd sm-mta[1103]: starting daemon (8.14.7): SMTP+queueing@00:30:00
Feb  9 09:44:46 vbsd sm-mta[1103]: STARTTLS=server: file /etc/mail/certs/dh.param unsafe: No such file or directory
Feb  9 09:45:36 vbsd sm-msp-queue[1186]: starting daemon (8.14.7): queueing@00:30:00
Feb  9 09:51:37 vbsd sm-mta[850]: gethostbyaddr(10.0.2.15) failed: 1
Feb  9 09:51:37 vbsd sm-mta[1086]: starting daemon (8.14.7): SMTP+queueing@00:30:00
Feb  9 09:51:37 vbsd sm-mta[1086]: STARTTLS=server: file /etc/mail/certs/dh.param unsafe: No such file or directory
Feb  9 09:52:26 vbsd sm-msp-queue[1179]: starting daemon (8.14.7): queueing@00:30:00
 
Re: Why do some steps at boot take so long?

lionoceros said:
Looks like there's very little disk activity during those steps.

I changed the /bin/hostname command as you instructed. This is the output of /tmp/hostname.truss:
...
I'm not sure what information this gives me or if it provides any clues as to what could be delaying the hostname and sendmail commands.

Unfortunately, it gives you negative information: Running the hostname command takes 0.03 seconds. Meaning it can not explain why that whole step takes 12 seconds. Meaning the problem is elsewhere.

My suggestion for how to proceed: Go to the beginning and end of /etc/rc.d/hostname, and add a date command there, for example as follows:
Code:
echo -n Start of /etc/rc.d/hostname ""
date
...
echo -n End of /etc/rc.d/hostname ""
date
That will show you how long the whole script took. Now, this might be very frustrating, since it might take a small fraction of a second. In that case, the problem is not that script itself, but the one that runs before or after. So figure out which script runs before and after hostname, and start instrumenting it too.

By the way, I apologize for having sent you down the wrong path with putting truss into the hostname script. It looked like a good candidate, because that script seems to take 12 seconds, yet it is very simple.

Now completely changing gears: It's likely that gethostbyaddr and its friends are the root cause of the problem. Most likely, there is something broken in host name resolution, and that code tends to be full of retries and timeouts. Personally, my solution to all these problems is "simply" (conceptually simple and a lot of work): I always run a full BIND name server at home, which is authorative for all host names and IP addresses used in my domain and on my network, and which goes back to the normal DNS infrastructure (starting at the root servers) for the rest of the world. Setting this up takes an expert half hour, and a beginner would probably not even survive it, because it can be so frustrating that they will commit ritual suicide by swallowing a whole PCI board after 17 hours of debugging.

Here is where I would start: Make a list of all host names and IP addresses that are in use. Then add entries for all of them in /etc/hosts. As @wblock said: Write both the short version and the fully qualified version. Use the host and dig commands to verify that all your host names work correctly and quickly. Warning: When querying for IP addresses with dig, you have to manually convert them to names, so 192.168.0.1 turns into 1.0.168.192.in-addr.arpa, and your 10.0.2.15 would be 15.2.0.10.in-addr.arpa.

In the long run, you have to figure out what to do in the long run (<- bad pun). Even if you get your system to work with /etc/hosts, that may not be a good solution: if you have more than one machine at home, then /etc/hosts on every machine has to be correct and include all machines, meaning that it turns management into an order O(n^2) task. On the other hand, doing the "right" thing (meaning: set up a real server, which does DHCP serving, DNS serving, and is perfectly correctly organized) has high initial startup cost, to learn to do it. And debugging this stuff isn't easy, as you have found. Concrete advice for how to manage your network depends heavily on how many machines you have, and what their usage pattern will be.
 
Last edited by a moderator:
Re: Why do hostname and sendmail steps at boot take so long?

@ralphbsz, I appreciate your extensive help. I'll look into /etc/hosts and see what I can do there. My question now is why has this become more complicated all of a sudden? I have a relatively simple setup: just a FreeBSD virtual machine using VirtualBox's NAT networking. All host names and IP addresses, I would imagine, would just be vbsd.local, 127.0.0.1, and maybe 10.0.2.15 (which VirtualBox assigns to the guest).

Is there something that changed with FreeBSD 10 regarding sendmail? In 9.2 I don't believe the last two messages even appeared at boot.
 
Last edited by a moderator:
Re: Why do hostname and sendmail steps at boot take so long?

Note that sendmail is not the problem, DNS is. And yes, there have been changes with DNS in 10.0-RELEASE: BIND was replaced by Unbound and LDNS. However, these changes should not affect your system in this case.

What happens if you comment out the "search" line in your resolv.conf?
 
Re: Why do hostname and sendmail steps at boot take so long?

That didn't change the boot time. However, I learned a bit more:

/etc/resolv.conf is regenerated back to its original form (below) after a reboot
Code:
# Generated by resolvconf
search gateway.2wire.net
nameserver 192.168.1.254

Also these two links suggest that I should probably use 10.0.2.3 instead of 192.168.1.254 for my name server:
http://iftekhar.blogspot.com/2012/05/vi ... erver.html
https://forums.virtualbox.org/viewtopic ... 10&start=0

Is there a way I could change resolv.conf permanently using resolvconf? This is the output of # resolvconf -v
Code:
DOMAINS='gateway.2wire.net:192.168.1.254'
SEARCH='gateway.2wire.net'
NAMESERVERS='192.168.1.254'
LOCALNAMESERVERS=''
 
Re: Why do hostname and sendmail steps at boot take so long?

Alternatively, is there a way to run the network configuration program in bsdinstall and choose to configure my network manually rather than using DHCP? (If that would help.)
 
Re: Why do hostname and sendmail steps at boot take so long?

I'm still waiting to see /var/log/maillog. It's best to look right after # cd /etc/mail && make restart.
 
Re: Why do hostname and sendmail steps at boot take so long?

I have no experience with FreeBSD 10. Still running 9.X. Nor with VirtualBox.

If someone is changing /etc/resolv.conf, it's probably the DHCP client. You probably have your system configured to set the IP address by DHCP. There are ways to make it so the DHCP client doesn't change /etc/resolv.conf, they have been discussed here. Since my FreeBSD machine is not a DHCP client, I don't remember which ones work well.

If you want to stop using DHCP (and take the risk that the IP address you need to use suddenly changes!), the way I turn it off is: edit /etc/rc.conf, and replace
Code:
ifconfig_em0=DHCP
with
Code:
ifconfig_em0=" inet 192.168.0.1 netmask 255.255.255.0 broadcast 192.168.0.255 description 'House server external'"
(obviously replacing your IP addresses and description).

This process is risky. It would probably be a better idea to figure out how resolveconf works, but I haven't needed that yet, so I can't help.

Still, putting everything into /etc/hosts is a good idea to debug the problem, and make it go away (either temporarily or permanently).
 
Re: Why do hostname and sendmail steps at boot take so long?

@wblock@ I posted /var/log/maillog earlier, but here it is again:

Code:
Feb  7 18:44:19 vbsd newsyslog[651]: logfile first created
Feb  7 18:45:16 vbsd sm-mta[816]: gethostbyaddr(10.0.2.15) failed: 1
Feb  7 18:45:16 vbsd sm-mta[817]: starting daemon (8.14.7): SMTP+queueing@00:30:00
Feb  7 18:45:16 vbsd sm-mta[817]: STARTTLS=server: file /etc/mail/certs/dh.param unsafe: No such file or directory
Feb  7 18:46:03 vbsd sm-msp-queue[820]: starting daemon (8.14.7): queueing@00:30:00
Feb  7 19:10:11 vbsd sm-mta[792]: gethostbyaddr(10.0.2.15) failed: 1
Feb  7 19:10:11 vbsd sm-mta[793]: starting daemon (8.14.7): SMTP+queueing@00:30:00
Feb  7 19:10:11 vbsd sm-mta[793]: STARTTLS=server: file /etc/mail/certs/dh.param unsafe: No such file or directory
Feb  7 19:11:00 vbsd sm-msp-queue[796]: starting daemon (8.14.7): queueing@00:30:00
Feb  7 19:56:18 vbsd sm-mta[806]: gethostbyaddr(10.0.2.15) failed: 1
Feb  7 19:56:18 vbsd sm-mta[807]: starting daemon (8.14.7): SMTP+queueing@00:30:00
Feb  7 19:56:18 vbsd sm-mta[807]: STARTTLS=server: file /etc/mail/certs/dh.param unsafe: No such file or directory
Feb  7 19:57:08 vbsd sm-msp-queue[810]: starting daemon (8.14.7): queueing@00:30:00
Feb  7 20:40:09 vbsd sm-mta[804]: gethostbyaddr(10.0.2.15) failed: 1
Feb  7 20:40:09 vbsd sm-mta[805]: starting daemon (8.14.7): SMTP+queueing@00:30:00
Feb  7 20:40:09 vbsd sm-mta[805]: STARTTLS=server: file /etc/mail/certs/dh.param unsafe: No such file or directory
Feb  7 20:40:59 vbsd sm-msp-queue[808]: starting daemon (8.14.7): queueing@00:30:00
Feb  7 23:33:30 vbsd sm-mta[810]: gethostbyaddr(10.0.2.15) failed: 1
Feb  7 23:33:30 vbsd sm-mta[811]: starting daemon (8.14.7): SMTP+queueing@00:30:00
Feb  7 23:33:30 vbsd sm-mta[811]: STARTTLS=server: file /etc/mail/certs/dh.param unsafe: No such file or directory
Feb  7 23:34:19 vbsd sm-msp-queue[814]: starting daemon (8.14.7): queueing@00:30:00
Feb  7 23:37:21 vbsd sm-mta[801]: gethostbyaddr(10.0.2.15) failed: 1
Feb  7 23:37:21 vbsd sm-mta[802]: starting daemon (8.14.7): SMTP+queueing@00:30:00
Feb  7 23:37:21 vbsd sm-mta[802]: STARTTLS=server: file /etc/mail/certs/dh.param unsafe: No such file or directory
Feb  7 23:38:10 vbsd sm-msp-queue[805]: starting daemon (8.14.7): queueing@00:30:00
Feb  8 16:19:48 vbsd sm-mta[858]: gethostbyaddr(10.0.2.15) failed: 1
Feb  8 16:19:48 vbsd sm-mta[1098]: starting daemon (8.14.7): SMTP+queueing@00:30:00
Feb  8 16:19:48 vbsd sm-mta[1098]: STARTTLS=server: file /etc/mail/certs/dh.param unsafe: No such file or directory
Feb  8 16:20:37 vbsd sm-msp-queue[1188]: starting daemon (8.14.7): queueing@00:30:00
Feb  8 16:33:34 vbsd sm-mta[852]: gethostbyaddr(10.0.2.15) failed: 1
Feb  8 16:33:34 vbsd sm-mta[1088]: starting daemon (8.14.7): SMTP+queueing@00:30:00
Feb  8 16:33:34 vbsd sm-mta[1088]: STARTTLS=server: file /etc/mail/certs/dh.param unsafe: No such file or directory
Feb  8 16:34:23 vbsd sm-msp-queue[1181]: starting daemon (8.14.7): queueing@00:30:00
Feb  8 16:40:52 vbsd sm-mta[850]: gethostbyaddr(10.0.2.15) failed: 1
Feb  8 16:40:52 vbsd sm-mta[1086]: starting daemon (8.14.7): SMTP+queueing@00:30:00
Feb  8 16:40:52 vbsd sm-mta[1086]: STARTTLS=server: file /etc/mail/certs/dh.param unsafe: No such file or directory
Feb  8 16:41:41 vbsd sm-msp-queue[1180]: starting daemon (8.14.7): queueing@00:30:00
Feb  8 17:03:41 vbsd sm-mta[856]: gethostbyaddr(10.0.2.15) failed: 1
Feb  8 17:03:41 vbsd sm-mta[1092]: starting daemon (8.14.7): SMTP+queueing@00:30:00
Feb  8 17:03:41 vbsd sm-mta[1092]: STARTTLS=server: file /etc/mail/certs/dh.param unsafe: No such file or directory
Feb  8 17:04:30 vbsd sm-msp-queue[1185]: starting daemon (8.14.7): queueing@00:30:00
Feb  8 18:43:38 vbsd sm-mta[856]: gethostbyaddr(10.0.2.15) failed: 1
Feb  8 18:43:38 vbsd sm-mta[937]: starting daemon (8.14.7): SMTP+queueing@00:30:00
Feb  8 18:43:38 vbsd sm-mta[937]: STARTTLS=server: file /etc/mail/certs/dh.param unsafe: No such file or directory
Feb  8 18:43:55 vbsd sm-msp-queue[1020]: starting daemon (8.14.7): queueing@00:30:00
Feb  8 18:51:10 vbsd sm-mta[852]: gethostbyaddr(10.0.2.15) failed: 1
Feb  8 18:51:10 vbsd sm-mta[938]: starting daemon (8.14.7): SMTP+queueing@00:30:00
Feb  8 18:51:10 vbsd sm-mta[938]: STARTTLS=server: file /etc/mail/certs/dh.param unsafe: No such file or directory
Feb  8 18:51:27 vbsd sm-msp-queue[1016]: starting daemon (8.14.7): queueing@00:30:00
Feb  9 09:44:46 vbsd sm-mta[857]: gethostbyaddr(10.0.2.15) failed: 1
Feb  9 09:44:46 vbsd sm-mta[1103]: starting daemon (8.14.7): SMTP+queueing@00:30:00
Feb  9 09:44:46 vbsd sm-mta[1103]: STARTTLS=server: file /etc/mail/certs/dh.param unsafe: No such file or directory
Feb  9 09:45:36 vbsd sm-msp-queue[1186]: starting daemon (8.14.7): queueing@00:30:00
Feb  9 09:51:37 vbsd sm-mta[850]: gethostbyaddr(10.0.2.15) failed: 1
Feb  9 09:51:37 vbsd sm-mta[1086]: starting daemon (8.14.7): SMTP+queueing@00:30:00
Feb  9 09:51:37 vbsd sm-mta[1086]: STARTTLS=server: file /etc/mail/certs/dh.param unsafe: No such file or directory
Feb  9 09:52:26 vbsd sm-msp-queue[1179]: starting daemon (8.14.7): queueing@00:30:00
Feb  9 13:05:06 vbsd sm-mta[860]: gethostbyaddr(10.0.2.15) failed: 1
Feb  9 13:05:06 vbsd sm-mta[1094]: starting daemon (8.14.7): SMTP+queueing@00:30:00
Feb  9 13:05:07 vbsd sm-mta[1094]: STARTTLS=server: file /etc/mail/certs/dh.param unsafe: No such file or directory
Feb  9 13:05:56 vbsd sm-msp-queue[1189]: starting daemon (8.14.7): queueing@00:30:00
Feb  9 13:07:58 vbsd sm-mta[863]: gethostbyaddr(10.0.2.15) failed: 1
Feb  9 13:07:58 vbsd sm-mta[1099]: starting daemon (8.14.7): SMTP+queueing@00:30:00
Feb  9 13:07:58 vbsd sm-mta[1099]: STARTTLS=server: file /etc/mail/certs/dh.param unsafe: No such file or directory
Feb  9 13:08:47 vbsd sm-msp-queue[1192]: starting daemon (8.14.7): queueing@00:30:00
Feb  9 13:11:16 vbsd sm-mta[863]: gethostbyaddr(10.0.2.15) failed: 1
Feb  9 13:11:16 vbsd sm-mta[1099]: starting daemon (8.14.7): SMTP+queueing@00:30:00
Feb  9 13:11:16 vbsd sm-mta[1099]: STARTTLS=server: file /etc/mail/certs/dh.param unsafe: No such file or directory
Feb  9 13:12:05 vbsd sm-msp-queue[1192]: starting daemon (8.14.7): queueing@00:30:00
Feb  9 17:20:08 vbsd sm-mta[1099]: restarting /usr/sbin/sendmail due to signal
Feb  9 17:20:08 vbsd sm-msp-queue[1192]: restarting /usr/sbin/sendmail due to signal
Feb  9 17:22:13 vbsd sm-mta[851]: gethostbyaddr(10.0.2.15) failed: 1
Feb  9 17:22:13 vbsd sm-mta[1107]: starting daemon (8.14.7): SMTP+queueing@00:30:00
Feb  9 17:22:13 vbsd sm-mta[1107]: STARTTLS=server: file /etc/mail/certs/dh.param unsafe: No such file or directory
Feb  9 17:23:02 vbsd sm-msp-queue[1180]: starting daemon (8.14.7): queueing@00:30:00

I just created the file /etc/resolvconf.conf and added the following:
Code:
search_domains="10.0.2.2"
name_server="10.0.2.3"
Then updated with # resolvconf -u using information from http://pivotallabs.com/using-resolvconf-conf-to-tweak-resolv-conf/ and http://iftekhar.blogspot.com/2012/05/virtualbox-dhcp-nameserver.html.

Didn't work.
 
Last edited by a moderator:
Re: Why do hostname and sendmail steps at boot take so long?

IFrom the log, Sendmail is looking for 10.0.2.15 to resolve. Why not just enter that in /etc/hosts? If it does not resolve to the right name, the log should show what name it expects.
 
Back
Top