Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm having a problem where calling "sendmail" results in it just sitting there for about 5 seconds before doing anything. I tried calling it with "-d" and this is the output:

# sendmail -d [My email] <testmail 
Exim version 4.76 uid=0 gid=0 pid=3711 D=fbb95cfd
Berkeley DB: Berkeley DB 5.1.25: (January 28, 2011)
Support for: crypteq iconv() IPv6 GnuTLS move_frozen_messages DKIM
Lookups (built-in): lsearch wildlsearch nwildlsearch iplsearch cdb dbm dbmnz dnsdb dsearch nis nis0 passwd
Authenticators: cram_md5 plaintext
Routers: accept dnslookup ipliteral manualroute queryprogram redirect
Transports: appendfile/maildir/mailstore autoreply lmtp pipe smtp
Fixed never_users: 0
Size of off_t: 8
Compiler: GCC [4.6.3]
Library version: GnuTLS: Compile: 2.12.14
                         Runtime: 2.12.14
Library version: PCRE: Compile: 8.12
                       Runtime: 8.12 2011-01-15
Total 12 lookups
TRUSTED_CONFIG_LIST: "/etc/exim4/trusted_configs"
changed uid/gid: forcing real = effective
  uid=0 gid=0 pid=3711
  auxiliary group list: <none>
seeking password data for user "uucp": cache not available
getpwnam() succeeded uid=10 gid=10

It then sits and does nothing for 5 to 10 seconds, before continuing.

configuration file is /var/lib/exim4/config.autogenerated
log selectors = 00000ffc 00612001
cwd=/root 3 args: sendmail -d [My email]

What is it doing during this time, and how to do I get it to stop? Frustratingly, specifying "-odb" to make it run in the background does not solve the problem - it backgrounds after the delay.

I'm running Exim 4.76 on Ubuntu Server 12.04. Exim is configured to send all email through a smarthost.

Here's the output of strace:

 getpwnam() succeeded uid=10 gid=10
 open("/etc/resolv.conf", O_RDONLY|O_CLOEXEC) = 4
 open("/etc/resolv.conf", O_RDONLY|O_CLOEXEC) = 4
 open("/etc/host.conf", O_RDONLY|O_CLOEXEC) = 4
 open("/etc/hosts", O_RDONLY|O_CLOEXEC)  = 4
 open("/etc/", O_RDONLY|O_CLOEXEC) = 4
 open("/lib/x86_64-linux-gnu/", O_RDONLY|O_CLOEXEC) = 4
 open("/etc/hosts", O_RDONLY|O_CLOEXEC)  = 4
 configuration file is /var/lib/exim4/config.autogenerated

The "" line is the last one printed before the delay.

share|improve this question
Can you run strace -e open sendmail -d [My email] <testmail and add the output to your OP? That might give you a pointer as to where the block is. Failing that, remove the -e open for a spammier view of all the system calls. – SmallClanger Mar 15 '13 at 12:47
5 seconds? Sounds like a DNS issue. – symcbean Mar 15 '13 at 13:04
Output of strace added. – David Glover Mar 15 '13 at 14:03
Are you sure all (relay)-hosts in the sendmail config can be accessed quickly ? If sendmail has to wait a bit for DNS resolves to complete this sort of thing can happen. Put those hosts temporarily in /etc/hosts en see it that improves things. – Tonny Mar 15 '13 at 14:16
Aha! That was the solution. The top DNS server entry was pointing to a defunct server. Removed it, and now it's super-quick. If you submit that as an answer I'll mark it as correct. – David Glover Mar 15 '13 at 14:25
up vote 0 down vote accepted

Answered by Tonny in the comments - the first DNS server was invalid so it was waiting for it to timeout. Removing the invalid DNS entry solved the problem.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.