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.
shows identical lines in both cases.
Version-Release number of selected component (if applicable):
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 127.0.0.1:25 0.0.0.0:*
Expected Results: tcp 0 0 aaa.bbb.ccc.ddd:25
tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN
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
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.
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
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.
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.
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.
Created attachment 97165 [details]
Default main.cf, only inet_interfaces is modified.
Created attachment 97167 [details]
Output of posconf
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.
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:
127.0.0.1 hostname.example.com hostname localhost.localdomain
This line causes such behavior of the postfix.
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.
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 :(