cron and dig

[Jim Reid]

>>>>> "Bruce" == Bruce Ordway <ordway at uswest.net> writes:

    Bruce> Hi, I've been working on sendmail and DNS. I recently tried
    Bruce> to automate my refresh of the db.cache file with cron.  I

There's no need to do this. For one thing, the "master" copy of this
file hasn't changed in a *long* time. [The one at ftp.rs.internic.net
was last modified in May last year, but it's identical to the one that
dated August 1997 that was shipped by my OS vendor.] A daily check
seems pointless. For another, your name server only uses this file
once each time it starts: the hints in the file are used to ask about
the A and NS records of the root servers. So as long as one of the
hints in the db.cache file works, that's all your name server
needs. For yet another your cron job assumes that lookups to
e.root-servers.net never fail. What if there's a connectivity problem
or if that server isn't handling queries because it's loading some
huge zone file like the one for .com?

    Bruce> Today I checked the contents of my /var/log/cron file and
    Bruce> saw the following lines:

    Bruce> (01/22-01:20:15-5343) MAIL (mailed 80 bytes of output but
    Bruce> got status 0x0046)

    Bruce> I am assuming that there was some mail sent about what
    Bruce> happened with getDNS when cron executed the command. I am
    Bruce> also assuming that the message had a probelm because I have
    Bruce> been screwing around with sendmail.

    Bruce> My question is this: How can I figure out what this means?
    Bruce> root (01/22-01:20:15-5343) MAIL (mailed 80 bytes of output
    Bruce> but got status 0x0046)

The chances are that your cron job decided to send mail because you
didn't arrange to redirect its output and error output somewhere.
[Check your local documentation for cron.] The exit status of that
mail process was 0x46. If you consult the local man pages for wait() -
or look at /usr/include/sys/wait.h - you should be able to decode that
exit status. You could also put more debugging and tracing info into
this getDNS shell script to figure out what it's doing and what is
going wrong. There may already be information about that in your
system's mail logs.

Personally, I wouldn't waste any time on this other than to find out
what, if anything, is going wrong with mail.