Hide Forgot
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 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): postfix-2.0.11-4 How reproducible: Always 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:* LISTEN Expected Results: tcp 0 0 aaa.bbb.ccc.ddd:25 0.0.0.0:* LISTEN tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN Additional info:
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. John
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 postfix-2.0.16. 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 localhost This line causes such behavior of the postfix. Thanks
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 :(