Re: Cyrus stops responding to imap:143 requests
On Fri, October 15, 2010 11:41 am, Rodrigo Ventura wrote:
Hello all,
for some time now we have been bugged with this problem: in our setup we have
cyrus-imapd (on HOST1) listening to both imaps:993 and imap:143 ports, the
former for the users, and the latter for a saslauthd -a rimap running on
another host (on HOST2; for SMTP AUTH purposes). While the imaps:993 has been
working flawlessly, from time to time imap:143 stops working. The socket is
still there, LISTENing, but when telnet'ing it it does not respond:
HOST2$ telnet HOST1 imap
Trying HOST1...
Connected to HOST1.
Escape character is '^]'.
The connection is established:
HOST2$ netstat -ntpe | grep 84545334
(Not all processes could be identified, non-owned process info
will not be shown, you would have to be root to see it all.) tcp0
0 HOST2:49774 HOST1:143 ESTABLISHED1000 84545334
2310/telnet
but on the other side:
HOST1# netstat -ntpae|grep :49774
tcp0 0 HOST1:143 HOST2:49774 SYN_RECV0 0
-
Now, on the HOST1 side, master preforks several imapd -s and imapd
processes, but while there is a imapd -s listening to 993:
# netstat -ntpa|grep 0.0.0.0:993
tcp0 0 0.0.0.0:993 0.0.0.0:* LISTEN
725/imapd
it is master who is listening to 143:
# netstat -ntpa|grep 0.0.0.0:143
tcp0 0 0.0.0.0:143 0.0.0.0:* LISTEN
28090/master
But what is really strange is that master does not seem to include the
LISTENing port in its select() call:
# netstat -ntpae | grep master
tcp0 0 0.0.0.0:110 0.0.0.0:* LISTEN
0 24593785 28090/master tcp0 0 0.0.0.0:143
0.0.0.0:* LISTEN 0 *24593773* 28090/master
tcp0 0 0.0.0.0:20030.0.0.0:* LISTEN
0 24593803 28090/master tcp0 0 :::993
:::*LISTEN 0 24593777 28090/master
tcp0 0 :::995 :::*LISTEN
0 24593789 28090/master tcp0 0 :::110
:::*LISTEN 0 24593783 28090/master
tcp0 0 :::143 :::*LISTEN
0 24593771 28090/master tcp0 0 :::2000
:::*LISTEN 0 24593795 28090/master
tcp0 0 :::2003 :::*LISTEN
0 24593801 28090/master
# ls -laF /proc/28090/fd|grep socket
lrwx-- 1 root root 64 Oct 15 09:46*10*- socket:[24593773] lrwx--
1 root root 64 Oct 15 09:46 13 - socket:[24593777]
lrwx-- 1 root root 64 Oct 15 09:46 16 - socket:[24593779] lrwx-- 1
root root 64 Oct 15 09:46 19 - socket:[24593783] lrwx-- 1 root root 64
Oct 15 09:46 22 - socket:[24593785]
lrwx-- 1 root root 64 Oct 15 09:46 25 - socket:[24593789] lrwx-- 1
root root 64 Oct 15 09:46 28 - socket:[24593791] lrwx-- 1 root root 64
Oct 15 09:46 31 - socket:[24593795]
lrwx-- 1 root root 64 Oct 15 09:46 34 - socket:[24593797] lrwx-- 1
root root 64 Oct 15 09:46 37 - socket:[24593801] lrwx-- 1 root root 64
Oct 15 09:46 40 - socket:[24593803]
lrwx-- 1 root root 64 Oct 15 09:46 43 - socket:[24593805] lrwx-- 1
root root 64 Oct 15 09:46 46 - socket:[24593808] lrwx-- 1 root root 64
Oct 15 09:46 5 - socket:[24593753]
lrwx-- 1 root root 64 Oct 15 09:46 7 - socket:[24593771]
# strace -p 28090
Process 28090 attached - interrupt to quit
select(48, [8 11 14 17 20 23 26 29 32 35 38 41 44 47], NULL, NULL, {3,
544000}) = 1 (in [47], left {2, 30})
read(47, \1\0\0\0\2330\0\0, 8)= 8 [...]
The dirty way of solving this is to kill and restart master again, but in the
meantime our users are no longer able to use SMTP AUTH from HOST2...
Any clues of what is going on here?
Cheers,
Rodrigo Ventura
ISR / IST
PS: after restarting master, it is still not including 143 on its select(),
but someone is responding to 143:
HOST2$ telnet HOST1 143
Trying HOST1...
Connected to HOST1.
Escape character is '^]'.
* OK [CAPABILITY IMAP4 IMAP4rev1 LITERAL+ ID STARTTLS AUTH=PLAIN AUTH=OTP
AUTH=DIGEST-MD5 AUTH=CRAM-MD5 SASL-IR COMPRESS=DEFLATE] HOST1 Cyrus IMAP
v2.3.16 server ready
HOST2$ netstat -ntpa|grep 143
(Not all processes could be identified, non-owned process info
will not be shown, you would have to be root to see it all.) tcp0
0 HOST2:33584 HOST1:143 ESTABLISHED3398/telnet
HOST1# netstat -ntpae|grep :33584
tcp0 0 HOST1:143 HOST2:33584 ESTABLISHED 96
27619330 18847/imapd
Rodrigo,
What does your /etc/cyrus.conf look like ?
In particular, pay attention to the way you make the Cyrus master
distinguish between different service names.
On 2.3.15, we run into a very similar situation whereby I
Re: Cyrus stops responding to imap:143 requests
On Wed, 27 Oct 2010, Eric Luyten wrote: On 2.3.15, we run into a very similar situation whereby I had made a distinction between two services using a suffix composed of a hyphen and some text, but Cyrus apparently only used the part before the hyphen in its internal housekeeping. Half of the time one service was responding, half of the time the other one. Very annoying. And an outright bug. If it won't work, it shouldn't be accepted. To make things clearer : problem situation : popserv cmd=pop3d -C ... popserv-sec cmd=pop3d -s -C ... problemless situation : popserv cmd=pop3d -C ... popservseccmd=pop3d -s -C ... Finding the solution was helped by us noticing that syslogging was also only done using the first part of the service name (popserv). Please file a bug about this issue, if you haven't done so already. http://bugzilla.cyrusimap.org/ -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Cyrus stops responding to imap:143 requests
On Wed, Oct 27, 2010 at 07:28:22PM -0200, Henrique de Moraes Holschuh wrote: On Wed, 27 Oct 2010, Eric Luyten wrote: On 2.3.15, we run into a very similar situation whereby I had made a distinction between two services using a suffix composed of a hyphen and some text, but Cyrus apparently only used the part before the hyphen in its internal housekeeping. Half of the time one service was responding, half of the time the other one. Very annoying. And an outright bug. If it won't work, it shouldn't be accepted. To make things clearer : problem situation : popserv cmd=pop3d -C ... popserv-sec cmd=pop3d -s -C ... problemless situation : popserv cmd=pop3d -C ... popservseccmd=pop3d -s -C ... Finding the solution was helped by us noticing that syslogging was also only done using the first part of the service name (popserv). Please file a bug about this issue, if you haven't done so already. http://bugzilla.cyrusimap.org/ Feel free to mark it up pretty high for backport to 2.3.x and into 2.4 as well - that's an evil bug! Bron. Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Cyrus stops responding to imap:143 requests
Hello all,
for some time now we have been bugged with this problem: in our setup we have
cyrus-imapd (on HOST1) listening to both imaps:993 and imap:143 ports, the
former for the users, and the latter for a saslauthd -a rimap running on
another host (on HOST2; for SMTP AUTH purposes). While the imaps:993 has been
working flawlessly, from time to time imap:143 stops working. The socket is
still there, LISTENing, but when telnet'ing it it does not respond:
HOST2$ telnet HOST1 imap
Trying HOST1...
Connected to HOST1.
Escape character is '^]'.
The connection is established:
HOST2$ netstat -ntpe | grep 84545334
(Not all processes could be identified, non-owned process info
will not be shown, you would have to be root to see it all.)
tcp0 0 HOST2:49774 HOST1:143 ESTABLISHED1000
84545334 2310/telnet
but on the other side:
HOST1# netstat -ntpae|grep :49774
tcp0 0 HOST1:143 HOST2:49774 SYN_RECV0 0
-
Now, on the HOST1 side, master preforks several imapd -s and imapd processes,
but while there is a imapd -s listening to 993:
# netstat -ntpa|grep 0.0.0.0:993
tcp0 0 0.0.0.0:993 0.0.0.0:* LISTEN
725/imapd
it is master who is listening to 143:
# netstat -ntpa|grep 0.0.0.0:143
tcp0 0 0.0.0.0:143 0.0.0.0:* LISTEN
28090/master
But what is really strange is that master does not seem to include the
LISTENing port in its select() call:
# netstat -ntpae | grep master
tcp0 0 0.0.0.0:110 0.0.0.0:* LISTEN
0 24593785 28090/master
tcp0 0 0.0.0.0:143 0.0.0.0:* LISTEN
0 *24593773* 28090/master
tcp0 0 0.0.0.0:20030.0.0.0:* LISTEN
0 24593803 28090/master
tcp0 0 :::993 :::*LISTEN
0 24593777 28090/master
tcp0 0 :::995 :::*LISTEN
0 24593789 28090/master
tcp0 0 :::110 :::*LISTEN
0 24593783 28090/master
tcp0 0 :::143 :::*LISTEN
0 24593771 28090/master
tcp0 0 :::2000 :::*LISTEN
0 24593795 28090/master
tcp0 0 :::2003 :::*LISTEN
0 24593801 28090/master
# ls -laF /proc/28090/fd|grep socket
lrwx-- 1 root root 64 Oct 15 09:46*10*- socket:[24593773]
lrwx-- 1 root root 64 Oct 15 09:46 13 - socket:[24593777]
lrwx-- 1 root root 64 Oct 15 09:46 16 - socket:[24593779]
lrwx-- 1 root root 64 Oct 15 09:46 19 - socket:[24593783]
lrwx-- 1 root root 64 Oct 15 09:46 22 - socket:[24593785]
lrwx-- 1 root root 64 Oct 15 09:46 25 - socket:[24593789]
lrwx-- 1 root root 64 Oct 15 09:46 28 - socket:[24593791]
lrwx-- 1 root root 64 Oct 15 09:46 31 - socket:[24593795]
lrwx-- 1 root root 64 Oct 15 09:46 34 - socket:[24593797]
lrwx-- 1 root root 64 Oct 15 09:46 37 - socket:[24593801]
lrwx-- 1 root root 64 Oct 15 09:46 40 - socket:[24593803]
lrwx-- 1 root root 64 Oct 15 09:46 43 - socket:[24593805]
lrwx-- 1 root root 64 Oct 15 09:46 46 - socket:[24593808]
lrwx-- 1 root root 64 Oct 15 09:46 5 - socket:[24593753]
lrwx-- 1 root root 64 Oct 15 09:46 7 - socket:[24593771]
# strace -p 28090
Process 28090 attached - interrupt to quit
select(48, [8 11 14 17 20 23 26 29 32 35 38 41 44 47], NULL, NULL, {3, 544000})
= 1 (in [47], left {2, 30})
read(47, \1\0\0\0\2330\0\0, 8)= 8
[...]
The dirty way of solving this is to kill and restart master again, but in the
meantime our users are no longer able to use SMTP AUTH from HOST2...
Any clues of what is going on here?
Cheers,
Rodrigo Ventura
ISR / IST
PS: after restarting master, it is still not including 143 on its select(), but
someone is responding to 143:
HOST2$ telnet HOST1 143
Trying HOST1...
Connected to HOST1.
Escape character is '^]'.
* OK [CAPABILITY IMAP4 IMAP4rev1 LITERAL+ ID STARTTLS AUTH=PLAIN AUTH=OTP
AUTH=DIGEST-MD5 AUTH=CRAM-MD5 SASL-IR COMPRESS=DEFLATE] HOST1 Cyrus IMAP
v2.3.16 server ready
HOST2$ netstat -ntpa|grep 143
(Not all processes could be identified, non-owned process info
will not be shown, you would have to be root to see it all.)
tcp0 0 HOST2:33584 HOST1:143 ESTABLISHED3398/telnet
HOST1# netstat -ntpae|grep :33584
tcp0 0 HOST1:143 HOST2:33584 ESTABLISHED 96
27619330 18847/imapd
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
