On Sunday 25 May 2008 18:42, Marc Haber wrote: > On Sat, May 24, 2008 at 04:44:27AM +1000, Andrew Vaughan wrote: > > On Saturday 24 May 2008 02:43, Marc Haber wrote: > > > On Sat, May 17, 2008 at 07:34:22PM +1000, Andrew Vaughan wrote: > > > > I changed the hostname on my home server. I changed /etc/hostname > > > > and /etc/mailname, rebooted and ran dpkg-reconfigure exim4-config > > > > thinking that that should be enough to get exim configured for the > > > > new hostname. > > > > > > Did you also change your /etc/hosts? > > > > No, but the new hostname is listed as an alias (and has been for 2 > > years). > > > > Experimenting shows that this does seem to the the problem. > > Yes, it is. Exim tries to determine its FQDN on startup to be able to > correctly process the @ macro. Without /etc/hosts, the FQDN cannot > be correctly obtained since /etc/hostname only sets the unqualified > host name.
I wasn't even aware that the local machine should be listed in /etc/hosts. (In my case it was there because I edited /etc/hosts once, and then copied it to my other 2 machines). I note that if I remove that line, dpkg-reconfigure exim-config will happily complete, but that question 5 shows that exim-config doesn't know what the local hostname is. (Something complains "hostname: Unknown host", but exim-config doesn't seem to actually care about the error.) I guess that the FQDN at startup can legitimately be different from the FQDN at debconf question 3, otherwise you wouldn't be asking question 3. > > > Changing the order so that the new hostname is listed first fixes > > the displayed name in exim4-config question 5. I'll check whether > > mail from cron gets delivered. > > Does it work? yes > > > Perhaps exim4-config could be changed to automatically add > > /bin/hostname -a to the list of automatic list of "local domains" in > > debconf question 5. > > That is not necessary. The list of local domains always includes @, > which expands to the local host name on a correctly configured system. > I don't think that it is correct to work around local configuration > errors automatically. In general I agree. It's much better to detect and report the error. Deamons/config-tools should try to validate their configuration files as much as is reasonably possible. But if a config-tool can generate a configuration file that will work despite possible local configuration errors that the config-tool/daemon can't detect, then that is better IMO than the alternative of the daemon appearing to start ok, and working for some use-cases, but actually being misconfigured. In this case it simply occurred to me that a machine accepting mail for all of its hostname aliases would possibly be a reasonable default config, and is potentially desirable. > > > Note that I consider the fact that exim was unable to notify me about > > the stuck mail as part of the justification for the important bug > > severity. Thinking back to this, I actually misinterpreted the standard notification to sender (in this case root) that their mail is delayed/not undelivered as exim4 attempting to notifying root that there is stuck mail. If exim were to attempt to notify root of email problems, it should try to avoid letting the notification also get stuck. > > If you want to be notified about stuck messages, use eximstats on a > regular basis and/or install a log management/check package. > I don't want to be running such checks manually. But unless I'm missing something, I can't think of an easy way to automate such checks that would work when exim fails to deliver mail from cron? Thanks for your help. Feel free to close and/or downgrade this bug if you won't/can't make exim/exim-config more robust against this type of mis-configuration, and don't see any other issues from what I wrote above. Cheers Andrew V. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
