Error: Failed to connect to localhost:143 : Connection timed out

12 posts / 0 new
Last post
#1 Wed, 08/17/2011 - 13:48
Jasio

Error: Failed to connect to localhost:143 : Connection timed out

Hello,

After doing some searching on the Virtualmin forums for this error, I found three separate threads and all three issues were quickly rectified by starting postfix/dovecot. Unfortunately none of the methods posted in those threads were successful in solving my problem.

I am running Ubuntu 10.04 LTS with the Virtualmin package installed. Everything was running fine until we started to have problems with webmail. You are able to login and authenticate yourself via webmail but the inbox and folders fail to load and an error message pops up "Failed to connect to localhost:143 : Connection timed out"

I have gone ahead and made sure both postfix and dovecot are working- but they must be working because everything worked previously. Also- mail through third-party applications such as Outlook/Thunderbird continue to work without any issues- so the SMTP/Mailserver is running properly and delivering/sending mail. I am guessing that the issue must be related to Dovecot since the IMAP port 143 is timing out.

There is no firewall running, and I flushed iptables just in case and then stopped the service from starting up automatically. Looking at the following error logs: /var/usermin/miniserv.error => no errors. /var/usermin/miniserv.log => no errors.

I ran 'dovecot --error-log' and checked /var/syslog for the dovecot error dump but once again I could not find any error messages relating to IMAP or failure to load/find the mailbox.

My postfix/dovecot conf files remain unchanged- since they are delivering mail successfully as long as webmail is not used.

I made sure that dovecot.conf was listening for imap. protocols = imap imaps pop3 pop3s

I'm not quite sure what would have changed/caused webmail to no longer work. The issue is fairly recent and as far a I am aware there have been no updates done to the server.

Help/advice would be much appreciated.

Wed, 08/17/2011 - 14:00
andreychek

Howdy,

Hmm, well, let's start here... what output do you get if you run this command:

netstat -an | grep :143

Also, I know you checked this... but just for fun, what does this command output:

iptables -L -n

Wed, 08/17/2011 - 14:13
Jasio

Thanks for the prompt reply.

Here's the output of netstat

netstat -an | grep :143
tcp        0      0 0.0.0.0:143             0.0.0.0:*               LISTEN
tcp        0      1 76.72.161.36:46410      64.99.64.32:143         SYN_SENT
tcp        0      1 76.72.161.36:46409      64.99.64.32:143         SYN_SENT

And iptables

sudo iptables -L -n Chain INPUT (policy ACCEPT) target prot opt source destination

Chain FORWARD (policy ACCEPT) target prot opt source destination

Chain OUTPUT (policy ACCEPT) target prot opt source destination

  • Thanks
Wed, 08/17/2011 - 14:35
andreychek

Okay, so as you said, there's no firewall setup there. And it looks like Dovecot is listening on port 143, the port that timed out when you were trying to use the webmail.

What happens if you try to telnet to port 143 from on your server...

That is, if you log into your server over SSH, and then run this command:

telnet localhost 143

Do you get something like this:

Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
* OK [CAPABILITY IMAP4rev1 SASL-IR SORT THREAD=REFERENCES MULTIAPPEND UNSELECT LITERAL+ IDLE CHILDREN NAMESPACE LOGIN-REFERRALS STARTTLS AUTH=PLAIN] Dovecot ready.

Or does it hang or give an error of some kind?

-Eric

Wed, 08/17/2011 - 15:23
Jasio

I ran telnet localhost 143

telnet localhost 143 Trying 64.99.64.32... telnet: Unable to connect to remote host: Connection timed out

This is rather odd... I'm not sure where 64.99.64.32 comes from. This isn't part of our IP block.

Wed, 08/17/2011 - 16:28
andreychek

Aha, I wonder if there's a rogue entry in /etc/hosts that's causing some trouble.

What output do you get if you run "cat /etc/hosts"?

-Eric

Wed, 08/17/2011 - 17:25
Jasio

cat /etc/hosts

127.0.0.1       localhost
127.0.1.1       punchhousestudios.com   punchhousestudios

# The following lines are desirable for IPv6 capable hosts
::1     localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

The URL for the site is punchhousestudios.com and it should resolve to 76.72.161.36

Wed, 08/17/2011 - 17:41
andreychek

Hrm... something is definitely awry, but I'm not sure what yet :-)

Is your hostname set to "punchhousestudios.com"?

If so, that's not actually an FQDN (which would be in the format host.domain.tld), and that may be contributing to the problem.

I'd suggest making sure that your hostname is an FQDN, in the host.domain.tld format.

Once you do that, you'd want to edit your /etc/resolv.conf file, and change this line:

127.0.1.1       punchhousestudios.com   punchhousestudios

To instead read:

your.public.ip.address       host.domain.tld  host

Once you have all that set, try telneting to port 143 again and see what happens :-)

-Eric

Wed, 08/17/2011 - 18:56
Jasio

Okay,

Trying: telnet localhost 143 I get the following:

telnet localhost 143
Trying ::1...
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
* OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE STARTTLS AUTH=PLAIN] Dovecot ready.

I did changed /etc/hosts to the following:

127.0.0.1       punch.punchhousestudios.com punch localhost.localdomain localhost
76.72.161.36    punch.punchhousestudios.com     punch

# The following lines are desirable for IPv6 capable hosts
::1     localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

I changed the hostname to: punch.punchhousestudios.com (FQDN)

However, the same error still persists in Webmail. But at least we got IMAP to respond on localhost.

Wed, 08/17/2011 - 19:04
andreychek

That's a good start! I think we're almost there.

It's possible that Usermin just cached part of that previous connection attempt... you may just need to restart it by running this command:

/etc/init.d/usermin restart

Wed, 08/17/2011 - 19:19
Jasio

Heya,

Looks like that fixed it! Thanks for your very prompt and insightful help. I'll keep an eye on it and see if there are any other issues.

Any idea what happened? What I mean is- the /etc/hosts file was never altered before and webmail worked fine. What could have prompted the sudden adherence to FQDN?

Wed, 08/17/2011 - 19:30
andreychek

Well, I'm not entirely certain... but if you have a Virtual Server with the same name as your server's hostname, that can cause problems.

But, I'm not sure which problem along the way actually caused all the issues to start happening :-)

Also, it's possible the problem was in place earlier, but only showed up after something restarted Usermin.

I'm glad it's working now though!

-Eric

Topic locked