> Absolutely correct.
>
> > From what I can see there are 2 issues:
> > Permission denied: failed to chdir to /root
> >
> > and
> >
> > retry timeout exceeded end of retry processing
>
> And in this case, the relevant extracts are:
> -----------------------------< cut here
>-------------------------------
> LOG: 0 MAIN
> ** support@??? R=lookuphost T=remote_smtp: retry
time
> not reached for any host after a long failure period
> -----------------------------< cut here
>-------------------------------
> and:
> -----------------------------< cut here
>-------------------------------
> delivering root@??? as root using
local_delivery:
> uid=99 gid=99 home=/root current=/root
> auxiliary group list: <none>
> search_tidyup called
> local_delivery transport returned DEFER for
> root@???
> added retry item for T:root@???: errno=13 0
> flags=0
> post-process root@??? (1)
> LOG: 0 MAIN
> == root@??? T=local_delivery defer (13):
> Permission denied: failed to chdir to /root
> -----------------------------< cut here
>-------------------------------
>
> The second line in the second extract:
> uid=99 gid=99 home=/root current=/root
> says that the current working directory is /root but the uid is
99,
> which presumably is that of the "exim" (or whatever) user. And
then the
> later errors just show that the permissions on /root don't
allow uid 99
> to chdir there.
>
> Does "local_delivery" try to deliver into something like
$HOME/.mail ?
> If so, what does "exim -bP never_users" show? Really, it's a
bad idea
> to read mail as root or to start deliveries as that user.
Perhaps add
> an alias redirecting the mail to the administrator's normal
account.
> "never_users = root" is in the default Exim config.
>
> If it's not that and it's just that Exim's delivery in test
stuff is
> trying to chdir to the current working directory of when Exim
was
> invoked, then try "cd /" and then run the test again. :^)
>
>
> Retry timeouts -- the retry hints say that there's a problem.
If you're
> just testing, perhaps you should blow away the hints database.
It's
> always _safe_ to do that. Desirable? Depends upon how much
mail you're
> shifting and how many useful hints are stored up. :^)
>
> # cd `exim -bP spool_directory|cut -d ' ' -f 3`/db
> (or, commonly, "cd /var/spool/exim/db")
> # rm retry*
Well I tried that and managed to kill Exim, got it back up and
running but now I am getting this error:
support@???
No route to host:
retry timeout exceeded
Thinking perhaps I have a resolv.conf or DNS issue, still looking
for ideas.
