[Dovecot] No localhost after reboot
Rebooted the server box today. Now Dovecot doesn't listen at localhost. It does listen at the LAN interface, so it is perfectly usable, but...
Does anyone have any idea why it has stopped listening at localhost?
Bob Hall
On Wed, 2003-08-27 at 07:17, Bob Hall wrote:
Rebooted the server box today. Now Dovecot doesn't listen at localhost. It does listen at the LAN interface, so it is perfectly usable, but...
Does anyone have any idea why it has stopped listening at localhost?
If settings still say imap_listen = *, it's probably got something to do with IPv6.. I think localhost was defined as ::1 in BSDs.. I'm not sure why it worked before then :)
On Wed, Aug 27, 2003 at 06:43:23PM +0300, Timo Sirainen wrote:
On Wed, 2003-08-27 at 07:17, Bob Hall wrote:
Rebooted the server box today. Now Dovecot doesn't listen at localhost. It does listen at the LAN interface, so it is perfectly usable, but...
Does anyone have any idea why it has stopped listening at localhost?
If settings still say imap_listen = *, it's probably got something to do with IPv6.. I think localhost was defined as ::1 in BSDs.. I'm not sure why it worked before then :)
I've tried both of the following: imap_listen = * imap_listen = <mailhost>:143 They behave the same; no localhost. Prior to the reboot, I was using localhost on a daily basis for testing. I never use IP6 for anything, so the OS kernel is compiled without IP6 support. When I try to log in, I get $ telnet localhost 143 Trying 127.0.0.1... so the system is trying to connect on an IP4 interface.
Bob Hall
On Wed, 2003-08-27 at 20:47, Bob Hall wrote:
imap_listen = *
What does "netstat -na|grep 143" say with this?
imap_listen = <mailhost>:143 They behave the same; no localhost. Prior to the reboot, I was using localhost on a daily basis for testing. I never use IP6 for anything, so the OS kernel is compiled without IP6 support. When I try to log in, I get $ telnet localhost 143 Trying 127.0.0.1... so the system is trying to connect on an IP4 interface.
OK, so it's not that then.
On Thu, Aug 28, 2003 at 03:57:30AM +0300, Timo Sirainen wrote:
On Wed, 2003-08-27 at 20:47, Bob Hall wrote:
imap_listen = *
What does "netstat -na|grep 143" say with this?
It says that the server is listening at that port and there are users connected, but that's on the LAN interface. There's no mention of 127.0.0.1. If I try to open a connection from the command line, netstat reports SYN_SENT to 127.0.0.1:143, but there's no response and no connection is established.
imap_listen = <mailhost>:143 They behave the same; no localhost. Prior to the reboot, I was using localhost on a daily basis for testing. I never use IP6 for anything, so the OS kernel is compiled without IP6 support. When I try to log in, I get $ telnet localhost 143 Trying 127.0.0.1... so the system is trying to connect on an IP4 interface.
OK, so it's not that then.
Ever since tools got more complicated than the hammer, civilization has been going downhill. Hammers use binary logic; if you hit something, it either goes <bang> or <splat>. I don't know what computers use; pixie dust maybe?
Bob Hall
On Wed, 27 Aug 2003 22:38:50 -0400 "Bob Hall" rjhjr@cox.net wrote:
Ever since tools got more complicated than the hammer, civilization has been going downhill. Hammers use binary logic; if you hit something, it either goes <bang> or <splat>. I don't know what computers use; pixie dust maybe?
Magic smoke, actually. You can tell, 'cause when the magic smoke escapes from inside, then the machine stops working. A hammer can be used to prove this thesis (but it's a ternary-logic hammer; in this case, it generally goes <crunch>).
Amy!
Amelia A. Lewis amyzing {at} talsever.com Tongue-tied and twisted, just an earthbound misfit, I. -- Pink Floyd
On Wed, Aug 27, 2003 at 11:24:59PM -0400, Amelia A. Lewis wrote:
On Wed, 27 Aug 2003 22:38:50 -0400 "Bob Hall" rjhjr@cox.net wrote:
Ever since tools got more complicated than the hammer, civilization has been going downhill. Hammers use binary logic; if you hit something, it either goes <bang> or <splat>. I don't know what computers use; pixie dust maybe?
Magic smoke, actually. You can tell, 'cause when the magic smoke escapes from inside, then the machine stops working. A hammer can be
You mean the smoke emitting diodes weren't designed that way?
used to prove this thesis (but it's a ternary-logic hammer; in this case, it generally goes <crunch>).
I wouldn't know. I prefer to use a rock on computers. It doesn't make the computer work better, but the juxtaposition of the geological and the computational seems to restore harmony in the universe.
Bob Hall
Bob Hall
On Thursday, Aug 28, 2003, at 05:38 Europe/Helsinki, Bob Hall wrote:
What does "netstat -na|grep 143" say with this?
It says that the server is listening at that port and there are users connected, but that's on the LAN interface.
So it's listening in "xx.xx.xx.xx.143", not "*.143"? What about other services?
Anyway, I don't really know. Default is to listen in all IPv4 interfaces and that's what imap_listen = * does too.
On Thu, Aug 28, 2003 at 06:39:04AM +0300, Timo Sirainen wrote:
On Thursday, Aug 28, 2003, at 05:38 Europe/Helsinki, Bob Hall wrote:
What does "netstat -na|grep 143" say with this?
It says that the server is listening at that port and there are users connected, but that's on the LAN interface.
So it's listening in "xx.xx.xx.xx.143", not "*.143"? What about other services?
I'm sorry, I should have quoted the output instead of interpreting it. <IP address> is the address for the mail server. <IP address>.143 <IP address>.1240 ESTABLISHED <IP address>.1240 <IP address>.143 ESTABLISHED <IP address>.143 *.* LISTEN That what it says right now. At other times, you can see connections from other computers.
Anyway, I don't really know. Default is to listen in all IPv4 interfaces and that's what imap_listen = * does too.
The output doesn't change if I set imap_listen = <server name>.143 or imap_listen = *
Bob Hall
"Bob Hall" rjhjr@cox.net writes:
On Thu, Aug 28, 2003 at 03:57:30AM +0300, Timo Sirainen wrote:
On Wed, 2003-08-27 at 20:47, Bob Hall wrote:
imap_listen = *
What does "netstat -na|grep 143" say with this?
It says that the server is listening at that port and there are users connected, but that's on the LAN interface. There's no mention of 127.0.0.1. If I try to open a connection from the command line, netstat reports SYN_SENT to 127.0.0.1:143, but there's no response and no connection is established.
Check your firewall settings and make sure your loopback device is up and configured and working. Check /etc/resolv.conf and DNS servers perhaps.
SYN_SENT shouldn't happen for loopback connections.
On Fri, Aug 29, 2003 at 02:59:18AM +0200, Matthias Andree wrote:
"Bob Hall" rjhjr@cox.net writes:
On Thu, Aug 28, 2003 at 03:57:30AM +0300, Timo Sirainen wrote:
On Wed, 2003-08-27 at 20:47, Bob Hall wrote:
imap_listen = *
What does "netstat -na|grep 143" say with this?
It says that the server is listening at that port and there are users connected, but that's on the LAN interface. There's no mention of 127.0.0.1. If I try to open a connection from the command line, netstat reports SYN_SENT to 127.0.0.1:143, but there's no response and no connection is established.
Check your firewall settings and make sure your loopback device is up and configured and working. Check /etc/resolv.conf and DNS servers perhaps.
SYN_SENT shouldn't happen for loopback connections.
Hmm. How are you going to establish a TCP connection without a handshake? The interface doesn't make any difference. Besides, it has nothing to do with Dovecot. Dovecot is the intended recipient, not the sender.
The LDAP server listens on localhost, and it currently has a connection established with dovecot-auth. Aside from Dovecot, NAT, DNS, Privoxy, and Squid all use localhost, so if the loopback wasn't working, I'd know about it pretty quickly. /etc/resolv.conf looks normal; it's got the search domains and the name server addresses.
Bob Hall
"Bob Hall" rjhjr@cox.net writes:
SYN_SENT shouldn't happen for loopback connections.
Hmm. How are you going to establish a TCP connection without a handshake?
Of course, SYN_SENT will be one state, but I find it intimidating that apparently all other services work but one on the same interface. There isn't really much that the application can do to prevent the kernel from returning ACK.
Are you running a firewall? Check its stats to see where the packets are lost. Are you running BPF-based applications? Might one of these hijack^Wdetour the packets?
The interface doesn't make any difference. Besides, it has nothing to do with Dovecot. Dovecot is the intended recipient, not the sender.
Shouldn't matter, the connection is bidirectional, but the SYN|ACK-packet is not getting returned -- and on lo0, it's kernel replying to itself, so it must work unless something is in the way.
Can you tcpdump port 143 on lo (or lo0)? Can you strace/truss/whichever the process listening on localhost's port 143 to see if it shows any other signs of life?
I've been SIGHUPing Dovecot when I make changes in dovecot.conf. This seemed to work fine; I made changes to the imap_listen setting and Dovecot accepted them. However, I just reset imap_listen = * and used killall instead of SIGHUP, and restarted, and Dovecot is listening on localhost. Previously, Dovecot would listen on both the LAN interface and localhost if I set imap_listen = <server name>:143 but now it listens only on the specified socket.
The reboot that changed Dovecot's behavior also changed my LDAP server. It was using CRYPT as the default without the --with-crypt flag. But after the reboot, I had to recompile OpenLADP with the --with-crypt flag. (The flag isn't mentioned in the instructions on the OpenLDAP site.)
Maybe I shouldn't have swapped keyboards during the reboot. Or maybe the keyboard uses the wrong brand of pixie dust. Or maybe I need to hit it with a hammer. Or maybe the power company flushed out some fat electrons when they cleaned the tap brushes on the dynamos...
Bob Hall
"Bob Hall" rjhjr@cox.net writes:
I've been SIGHUPing Dovecot when I make changes in dovecot.conf. This seemed to work fine; I made changes to the imap_listen setting and Dovecot accepted them. However, I just reset imap_listen = * and used killall instead of SIGHUP, and restarted, and Dovecot is
Don't do this on SysV (Solaris 8 has pkill instead) - killall kills EVERYTHING there. (used for shutting down the system).
Anyways, can we please have a decent set of manual pages for dovecot before 1.0 that specifies what is re-read after SIGHUP and what needs a full restart? :->
Maybe I shouldn't have swapped keyboards during the reboot. Or maybe the keyboard uses the wrong brand of pixie dust. Or maybe I need to hit it with a hammer. Or maybe the power company flushed out some fat electrons when they cleaned the tap brushes on the dynamos...
Maybe the current was the wrong color? <shrug> ;-) (One Power Co here in Germany is called Yello Strom)
On Sat, Aug 30, 2003 at 12:14:25AM +0200, Matthias Andree wrote:
"Bob Hall" rjhjr@cox.net writes:
I've been SIGHUPing Dovecot when I make changes in dovecot.conf. This seemed to work fine; I made changes to the imap_listen setting and Dovecot accepted them. However, I just reset imap_listen = * and used killall instead of SIGHUP, and restarted, and Dovecot is
Don't do this on SysV (Solaris 8 has pkill instead) - killall kills EVERYTHING there. (used for shutting down the system).
I suppose "kill <pid>" is more universal than "killall <process name>"? At any rate, use whatever sends the TERM signal.
Anyways, can we please have a decent set of manual pages for dovecot before 1.0 that specifies what is re-read after SIGHUP and what needs a full restart? :->
Maybe I shouldn't have swapped keyboards during the reboot. Or maybe the keyboard uses the wrong brand of pixie dust. Or maybe I need to hit it with a hammer. Or maybe the power company flushed out some fat electrons when they cleaned the tap brushes on the dynamos...
Maybe the current was the wrong color? <shrug> ;-) (One Power Co here in Germany is called Yello Strom)
And what do they use to generate "yello strom"; starkbier?
Bob Hall
On Saturday, Aug 30, 2003, at 01:14 Europe/Helsinki, Matthias Andree wrote:
Anyways, can we please have a decent set of manual pages for dovecot before 1.0 that specifies what is re-read after SIGHUP and what needs a full restart? :->
From TODO:
- bugs
- SIGHUP didn't update imap_listen. this is a bit annoying to fix
though, since new listen() may fail for a few times because login processes may not die immediately.. - SIGHUP doesn't update log file location.
participants (4)
-
Amelia A. Lewis
-
Bob Hall
-
Matthias Andree
-
Timo Sirainen