Bug 112633 - inet_interfaces = $myhostname, localhost binds postfix to only
Summary: inet_interfaces = $myhostname, localhost binds postfix to only
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: postfix   
(Show other bugs)
Version: 3.0
Hardware: i386 Linux
Target Milestone: ---
Assignee: Jeremy Katz
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2003-12-25 11:04 UTC by Victor Ashik
Modified: 2007-11-30 22:06 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-01-23 20:30:39 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Result of postconf -n (697 bytes, text/plain)
2004-01-22 15:14 UTC, Victor Ashik
no flags Details
Default main.cf, only inet_interfaces is modified. (24.91 KB, text/plain)
2004-01-22 15:16 UTC, Victor Ashik
no flags Details
Output of posconf (10.25 KB, text/plain)
2004-01-22 15:17 UTC, Victor Ashik
no flags Details

Description Victor Ashik 2003-12-25 11:04:17 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1)

Description of problem:
inet_interfaces = $myhostname, localhost

was working in Red Hat Linux 9, postfix-1.*

In RHEL3 it works if you have replaced $myhostname with ip address.

postconf inet_interfaces

shows identical lines in both cases.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.service sendmail stop
2.rpm -ivh postfix-2.0.11-4.i386.rpm
3.alternatives --set mta /usr/sbin/sendmail.postfix
4.sed -i 's@^inet_interfaces = localhost$@inet_interfaces =
$myhostname, localhost@' /etc/postfix/main.cf
5.service postfix start
6.netstat -nlt|grep :25

Actual Results:  tcp        0      0  *

Expected Results:  tcp        0      0 aaa.bbb.ccc.ddd:25*               LISTEN
tcp        0      0  *               LISTEN

Additional info:

Comment 1 John Dennis 2004-01-12 21:15:35 UTC
This proably is not a bug in postfix, but I have seen this problem
before, its usually a result of postfix being unable to either
determine you hostname, your hostname's FQDN, or DNS lookup failing on
postfix things your hostname is. Here are a few things to check:

Do a uname -a. Is your hostname a FQDN? In other words do you have a
domain part?

If no, then have you set mydomain in main.cf?

If you do a "host" or "dig" with your hostname with and without the
domain, do you get back your ip address?

This might sound silly, but also please verify in your main.cf that
the line that sets inet_interfaces with $myhostname, localhost is the
one actually parsed (i.e. its not commented out), its not unusal to
have many such lines in the file with only one being active.

Typcially when I've seen this problem its because your hostname is not
fully resolving, usually because its missing the domain.

Let me know what you find out.


Comment 2 Victor Ashik 2004-01-16 07:36:20 UTC
I have checked all that you asked.

uname -a gives FQDN with domain part.
host with that name gives ip address
line with $myhostname, localhost is one that parsed 

Comment 3 John Dennis 2004-01-21 22:59:30 UTC
I cannot reproduce this problem and given your answers above and what
I find in the postfix source I don't see an obvious way this might
manifest itself. At this point I suspect there is something in your
configuration file. Also, this is unrelated but you might want to
refer to bug 108960 which identifies an smtp problem with
postfix-2.0.11 which is what you have installed. The latest package is

I have two suggestions to diagnose if this is a config file problem.
Please run "postconf -n" capture the output and attach it to this bug
report so I can look at it. This command will print out any
non-default postfix configuration parameters. Also please attach the
verson of main.cf which provokes the problem for you.

Comment 4 John Dennis 2004-01-21 23:48:50 UTC
in additon to the "postconf -n" output please also include another
attachement with just the postconf output, that will show all
parameters and might be useful.

Comment 5 Victor Ashik 2004-01-22 15:14:21 UTC
Created attachment 97164 [details]
Result of postconf -n

I have just reproduced the situation using the default clear RHEL ES setup with
default main.cf file for postfix, exactly as I mentioned earlier.

Comment 6 Victor Ashik 2004-01-22 15:16:10 UTC
Created attachment 97165 [details]
Default main.cf, only inet_interfaces is modified.

Comment 7 Victor Ashik 2004-01-22 15:17:19 UTC
Created attachment 97167 [details]
Output of posconf

Comment 8 John Dennis 2004-01-22 21:54:28 UTC
I cannot reproduce this with any reliability. I got it to happen once
and that was immediately after setting postfix as the new mta. There
only seems to be two conditions that might be responsible. Either it
was because it was the first time postfix was run or because I forgot
to stop sendmail before the first invocation of postfix and there was
conflict over the port. This was on a machine with a fresh install of
RHEL3. Since then exercises with starting/stopping postfix and
rebooting the machine with your main.cf all produced a correctly
running implemention with port 25 being listened to on both the
localhost and hostname.

I've invested 2 days in trying to track this down and I'm coming to
the conclusion its not worth spending more time on unless we can get a
reliable reproducer or other customers get hit by the same issue. Thus
I'm going to close this out for now. However, I do strongly suggest
you upgrade to 2.0.16 as 2.0.11 has a known problem with MUA's such as
pine, MH, etc. I'm sorry I can't be of more help at the moment.

Comment 9 Victor Ashik 2004-01-23 07:51:18 UTC
With my colleague we found roots of the problem.
Postfix is not guilty here.
RHEL3 installer as RHL9 installer puts hostname to the /etc/hosts 
into one line with localhost: hostname.example.com hostname localhost.localdomain 

This line causes such behavior of the postfix.

Comment 10 John Dennis 2004-01-23 16:19:22 UTC
Jeremy, I've reopened this to see if you or one of the other anaconda
folks agree the installer does what is claimed in comment 9. I had
done a fresh 3.0E install and /etc/hosts did not have the hostname on
the loopback and I have a RHL 9 machine and /etc/hosts also does not
have the hostname on the loopback. So from my perspective it does not
look like the installer would put the hostname on the loopback but
that might be because of the way we do installs internally. I think it
might be worthwhile for someone familar with the installer to just
verify we're not somehow putting the hostname on the loopback.

Comment 11 Jeremy Katz 2004-01-23 20:30:39 UTC
There are cases when putting the hostname on the loopback interface is
the only reliable thing to do and we thus do it in those cases. 
Unfortunately, there's no 100% answer :(

Note You need to log in before you can comment on or make changes to this bug.