Re: idle pop3d never times out
On Mon, Apr 22, 2002 at 03:44:49PM -0400, Ilya wrote: > Have you found any solution, work around ? > I am having the same problem, with both imapd and pop3d It's okay for imapd to hang around, because the client can reuse the connection indefinitely. This is normal. IMAP clients can also make multiple connections, so they are not hampered if an old connection exists. It is unusual for pop3d to hang around, since POP clients must log in each time they check for new mail or download mail, and then close the connection when the operation is completed. Also, pop3d only allows one connection per client, which does cause client problems when an old connection exists. I have not found a solution, other than killing old pop3d processes. > as you see they hang there since wednesday. the clients are outlook express. > > 42564 0.0 0.2 2392 316 p2- IWed12AM 0:02.67 > /usr/local/cyrus2/bin/master > cyrus42821 0.0 0.4 3752 664 p2- IWed01AM 0:03.32 imapd: imapd: > alchemistry.net[192.168.0.3] (imapd) > cyrus70493 0.0 0.6 3820 996 ?? SWed07PM 0:00.73 imapd: imapd: > sharkjr[192.168.0.22] eugene user.eugene (imapd) > cyrus73125 0.0 0.4 3752 656 ?? IWed09PM 0:00.53 imapd: imapd: > alchemistry.net[192.168.0.3] (imapd) > cyrus73951 0.0 0.4 3752 596 ?? IWed10PM 0:00.34 imapd: imapd: > alchemistry.net[192.168.0.3] (imapd) -- -Gary Mills--Unix Support--U of M Academic Computing and Networking-
Re: idle pop3d never times out
Have you found any solution, work around ? I am having the same problem, with both imapd and pop3d as you see they hang there since wednesday. the clients are outlook express. 42564 0.0 0.2 2392 316 p2- IWed12AM 0:02.67 /usr/local/cyrus2/bin/master cyrus42821 0.0 0.4 3752 664 p2- IWed01AM 0:03.32 imapd: imapd: alchemistry.net[192.168.0.3] (imapd) cyrus70493 0.0 0.6 3820 996 ?? SWed07PM 0:00.73 imapd: imapd: sharkjr[192.168.0.22] eugene user.eugene (imapd) cyrus73125 0.0 0.4 3752 656 ?? IWed09PM 0:00.53 imapd: imapd: alchemistry.net[192.168.0.3] (imapd) cyrus73951 0.0 0.4 3752 596 ?? IWed10PM 0:00.34 imapd: imapd: alchemistry.net[192.168.0.3] (imapd) n Mon, Apr 15, 2002 at 07:28:34PM -0500, Gary Mills wrote: > On Tue, Apr 16, 2002 at 11:33:00AM +1200, Mike Brady wrote: > > This sounds very similar to a problem that I reported a couple of weeks ago > > with imapd not closing the socket in 2.1.3. Maybe there is something not > > quite right with the socket handling in 2.x in general. > > No, it's not the same. In my case pop3d was in the middle of a write > to the client. The client wasn't reading the data, causing the > connection to persist forever. > > -- > -Gary Mills--Unix Support--U of M Academic Computing and Networking- >
Re: idle pop3d never times out
On Mon, Apr 15, 2002 at 02:40:20PM -0400, Lawrence Greenfield wrote: >Date: Sun, 14 Apr 2002 18:35:18 -0500 >From: Gary Mills <[EMAIL PROTECTED]> > >electra.cc.umanitoba.ca -> net41.anthro.umanitoba.ca TCP D=2034 S=110 >Ack=1055534117 Seq=3063126801 Len=1 Win=24656 >net41.anthro.umanitoba.ca -> electra.cc.umanitoba.ca TCP D=110 S=2034 >Ack=3063126801 Seq=1055534117 Len=0 Win=0 > > It appears that the client is still there (you have an active TCP > session) but I don't know if it's making progress. Are the sequence > numbers changing? > > It's almost as if someone Ctrl-z'd the pop client on their machine. This is now looking like a client problem. The 12-day old POP session disappeared all by itself. A new pop3d was connected to the same workstation, and was also blocked in a TCP send. The user is running Eudora 3.x, and has not noticed a problem. -- -Gary Mills--Unix Support--U of M Academic Computing and Networking-
Re: idle pop3d never times out
On Tue, Apr 16, 2002 at 11:33:00AM +1200, Mike Brady wrote: > This sounds very similar to a problem that I reported a couple of weeks ago > with imapd not closing the socket in 2.1.3. Maybe there is something not > quite right with the socket handling in 2.x in general. No, it's not the same. In my case pop3d was in the middle of a write to the client. The client wasn't reading the data, causing the connection to persist forever. -- -Gary Mills--Unix Support--U of M Academic Computing and Networking-
RE: idle pop3d never times out
This sounds very similar to a problem that I reported a couple of weeks ago with imapd not closing the socket in 2.1.3. Maybe there is something not quite right with the socket handling in 2.x in general. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Gary Mills > Sent: Tuesday, 16 April 2002 10:05 a.m. > To: Lawrence Greenfield > Cc: [EMAIL PROTECTED] > Subject: Re: idle pop3d never times out > > > On Mon, Apr 15, 2002 at 02:40:20PM -0400, Lawrence Greenfield wrote: > > > > It appears that the client is still there (you have an active TCP > > session) but I don't know if it's making progress. Are the sequence > > numbers changing? > > No, they never change. I don't know much about TCP, but I'd say that > the client host is saying ``I'm full''. > > > It's almost as if someone Ctrl-z'd the pop client on their machine. > > > > Now, in terms on Cyrus: it's probably a bug (or at the very least a > > misfeature) that we don't implement any sort of timeout on write. > > This is mostly an implementation simplicity choice. > > I suppose it affects IMAP as well, but since IMAP allows multiple > sessions, the users don't notice. It looks as if I'll need to > add pop3d to my list of old processes that should be killed. > > -- > -Gary Mills--Unix Support--U of M Academic Computing and > Networking- > >
Re: idle pop3d never times out
On Mon, Apr 15, 2002 at 02:40:20PM -0400, Lawrence Greenfield wrote: > > It appears that the client is still there (you have an active TCP > session) but I don't know if it's making progress. Are the sequence > numbers changing? No, they never change. I don't know much about TCP, but I'd say that the client host is saying ``I'm full''. > It's almost as if someone Ctrl-z'd the pop client on their machine. > > Now, in terms on Cyrus: it's probably a bug (or at the very least a > misfeature) that we don't implement any sort of timeout on write. > This is mostly an implementation simplicity choice. I suppose it affects IMAP as well, but since IMAP allows multiple sessions, the users don't notice. It looks as if I'll need to add pop3d to my list of old processes that should be killed. -- -Gary Mills--Unix Support--U of M Academic Computing and Networking-
Re: idle pop3d never times out
On Mon, Apr 15, 2002 at 02:55:10PM -0400, Igor Brezac wrote: > > On Mon, 15 Apr 2002, Lawrence Greenfield wrote: > > > > It appears that the client is still there (you have an active TCP > > session) but I don't know if it's making progress. Are the sequence > > numbers changing? > > > > It's almost as if someone Ctrl-z'd the pop client on their machine. > > > > Now, in terms on Cyrus: it's probably a bug (or at the very least a > > misfeature) that we don't implement any sort of timeout on write. > > This is mostly an implementation simplicity choice. > > This can be a network problem. I've seen this multiple times on > improperly configured DS3 circuits or if you have errors on your NIC. Do > netstat -i or check your WAN circuits. That's unlikely in this case. Both client and server are on our campus network. -- -Gary Mills--Unix Support--U of M Academic Computing and Networking-
Re: idle pop3d never times out
On Mon, 15 Apr 2002, Lawrence Greenfield wrote: >Date: Sun, 14 Apr 2002 18:35:18 -0500 >From: Gary Mills <[EMAIL PROTECTED]> > [...] >Yes, there is traffic every few seconds with `snoop': > >electra.cc.umanitoba.ca -> net41.anthro.umanitoba.ca TCP D=2034 S=110 >Ack=1055534117 Seq=3063126801 Len=1 Win=24656 >net41.anthro.umanitoba.ca -> electra.cc.umanitoba.ca TCP D=110 S=2034 >Ack=3063126801 Seq=1055534117 Len=0 Win=0 > >My guess is that the mail reader on the client disappeared. > > It appears that the client is still there (you have an active TCP > session) but I don't know if it's making progress. Are the sequence > numbers changing? > > It's almost as if someone Ctrl-z'd the pop client on their machine. > > Now, in terms on Cyrus: it's probably a bug (or at the very least a > misfeature) that we don't implement any sort of timeout on write. > This is mostly an implementation simplicity choice. > This can be a network problem. I've seen this multiple times on improperly configured DS3 circuits or if you have errors on your NIC. Do netstat -i or check your WAN circuits. -Igor
Re: idle pop3d never times out
Date: Sun, 14 Apr 2002 18:35:18 -0500 From: Gary Mills <[EMAIL PROTECTED]> [...] Yes, there is traffic every few seconds with `snoop': electra.cc.umanitoba.ca -> net41.anthro.umanitoba.ca TCP D=2034 S=110 Ack=1055534117 Seq=3063126801 Len=1 Win=24656 net41.anthro.umanitoba.ca -> electra.cc.umanitoba.ca TCP D=110 S=2034 Ack=3063126801 Seq=1055534117 Len=0 Win=0 My guess is that the mail reader on the client disappeared. It appears that the client is still there (you have an active TCP session) but I don't know if it's making progress. Are the sequence numbers changing? It's almost as if someone Ctrl-z'd the pop client on their machine. Now, in terms on Cyrus: it's probably a bug (or at the very least a misfeature) that we don't implement any sort of timeout on write. This is mostly an implementation simplicity choice. Larry
Re: idle pop3d never times out
On Sun, Apr 14, 2002 at 06:49:44PM -0400, Lawrence Greenfield wrote: > > Hmm. So there's clearly some sort of problem in the socket > implementation then. If the packet can't be delivered successfully, > the write() system call is suppose to return EPIPE: > >The communications protocols which implement a SOCK_STREAM >ensure that data is not lost or duplicated. If a piece of data >for which the peer protocol has buffer space cannot be >successfully transmitted within a reasonable length of time, >then the connection is considered to be dead. When >SO_KEEPALIVE is enabled on the socket the protocol checks in a >protocol-specific manner if the other end is still alive. A >SIGPIPE signal is raised if a process sends or receives on a >broken stream; this causes naive processes, which do not handle >the signal, to exit. SOCK_SEQPACKET sockets employ the > > I guess I'd like to know if any data is trying to be transmitted to > the client (use "tcpdump host " on the server for a couple > of hours?). Yes, there is traffic every few seconds with `snoop': electra.cc.umanitoba.ca -> net41.anthro.umanitoba.ca TCP D=2034 S=110 Ack=1055534117 Seq=3063126801 Len=1 Win=24656 net41.anthro.umanitoba.ca -> electra.cc.umanitoba.ca TCP D=110 S=2034 Ack=3063126801 Seq=1055534117 Len=0 Win=0 My guess is that the mail reader on the client disappeared. > I don't consider 12 days a reasonable amount of time to have to wait. -- -Gary Mills--Unix Support--U of M Academic Computing and Networking-
Re: idle pop3d never times out
Date: Sun, 14 Apr 2002 17:19:33 -0500 From: Gary Mills <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED] On Sun, Apr 14, 2002 at 04:54:35PM -0400, Lawrence Greenfield wrote: > the Cyrus software will never interrupt a TCP send to obey the > timeouts; this guy isn't responding and a TCP send could take up to a > couple of hours to time out I think. After 12 days, I'd say it's not going to time out. Presumably, the PC was rebooted in the middle of the send. The user will be calling our support desk to report that her POP session is locked. Should I be running a cron command to kill old pop3d processes? I had hoped that the daemon would look after this case. Hmm. So there's clearly some sort of problem in the socket implementation then. If the packet can't be delivered successfully, the write() system call is suppose to return EPIPE: The communications protocols which implement a SOCK_STREAM ensure that data is not lost or duplicated. If a piece of data for which the peer protocol has buffer space cannot be successfully transmitted within a reasonable length of time, then the connection is considered to be dead. When SO_KEEPALIVE is enabled on the socket the protocol checks in a protocol-specific manner if the other end is still alive. A SIGPIPE signal is raised if a process sends or receives on a broken stream; this causes naive processes, which do not handle the signal, to exit. SOCK_SEQPACKET sockets employ the I guess I'd like to know if any data is trying to be transmitted to the client (use "tcpdump host " on the server for a couple of hours?). I don't consider 12 days a reasonable amount of time to have to wait. Larry
Re: idle pop3d never times out
On Sun, Apr 14, 2002 at 04:54:35PM -0400, Lawrence Greenfield wrote: > the Cyrus software will never interrupt a TCP send to obey the > timeouts; this guy isn't responding and a TCP send could take up to a > couple of hours to time out I think. After 12 days, I'd say it's not going to time out. Presumably, the PC was rebooted in the middle of the send. The user will be calling our support desk to report that her POP session is locked. Should I be running a cron command to kill old pop3d processes? I had hoped that the daemon would look after this case. >Date: Sun, 14 Apr 2002 11:17:23 -0500 >From: Gary Mills <[EMAIL PROTECTED]> > >I see this problem occasionally, and noticed one today: > > UID PID PPID CSTIME TTY TIME CMD > cyrus 6247 725 0 Apr 02 ?0:01 pop3d > >`lsof' shows that file descriptors 0, 1, and 2 have an established >TCP connection to a client workstation. `truss' shows: > >write(1, " A A V o 1 F 8 F D o M t".., 4096) (sleeping...) > >imapd.conf does not specify `poptimeout', so it should be the default >of ten minutes. Why didn't it time out? -- -Gary Mills--Unix Support--U of M Academic Computing and Networking-
Re: idle pop3d never times out
the Cyrus software will never interrupt a TCP send to obey the timeouts; this guy isn't responding and a TCP send could take up to a couple of hours to time out I think. Larry Date: Sun, 14 Apr 2002 11:17:23 -0500 From: Gary Mills <[EMAIL PROTECTED]> I see this problem occasionally, and noticed one today: UID PID PPID CSTIME TTY TIME CMD cyrus 6247 725 0 Apr 02 ?0:01 pop3d `lsof' shows that file descriptors 0, 1, and 2 have an established TCP connection to a client workstation. `truss' shows: write(1, " A A V o 1 F 8 F D o M t".., 4096) (sleeping...) imapd.conf does not specify `poptimeout', so it should be the default of ten minutes. Why didn't it time out? -- -Gary Mills--Unix Support--U of M Academic Computing and Networking-
Re: idle pop3d never times out
On Sun, Apr 14, 2002 at 01:50:31PM -0400, Ken Murchison wrote: > > Gary Mills wrote: > > > > I see this problem occasionally, and noticed one today: > > > > UID PID PPID CSTIME TTY TIME CMD > >cyrus 6247 725 0 Apr 02 ?0:01 pop3d > > > > `lsof' shows that file descriptors 0, 1, and 2 have an established > > TCP connection to a client workstation. `truss' shows: > > > > write(1, " A A V o 1 F 8 F D o M t".., 4096) (sleeping...) > > > > imapd.conf does not specify `poptimeout', so it should be the default > > of ten minutes. Why didn't it time out? > > Can you give us the output of cyradm 'ver'? I knew I forgot something when I posted that. Here it is: name : Cyrus version: v2.1.0pre vendor : Project Cyrus support-url: http://asg.web.cmu.edu/cyrus os : SunOS os-version : 5.8 environment: Cyrus SASL 1.5.27 Sleepycat Software: Berkeley DB 3.1.17: (July 31, 2000) OpenSSL 0.9.5a 1 Apr 2000 -- -Gary Mills--Unix Support--U of M Academic Computing and Networking-
Re: idle pop3d never times out
Gary Mills wrote: > > I see this problem occasionally, and noticed one today: > > UID PID PPID CSTIME TTY TIME CMD >cyrus 6247 725 0 Apr 02 ?0:01 pop3d > > `lsof' shows that file descriptors 0, 1, and 2 have an established > TCP connection to a client workstation. `truss' shows: > > write(1, " A A V o 1 F 8 F D o M t".., 4096) (sleeping...) > > imapd.conf does not specify `poptimeout', so it should be the default > of ten minutes. Why didn't it time out? Can you give us the output of cyradm 'ver'? -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key--http://www.oceana.com/~ken/ksm.pgp
idle pop3d never times out
I see this problem occasionally, and noticed one today: UID PID PPID CSTIME TTY TIME CMD cyrus 6247 725 0 Apr 02 ?0:01 pop3d `lsof' shows that file descriptors 0, 1, and 2 have an established TCP connection to a client workstation. `truss' shows: write(1, " A A V o 1 F 8 F D o M t".., 4096) (sleeping...) imapd.conf does not specify `poptimeout', so it should be the default of ten minutes. Why didn't it time out? -- -Gary Mills--Unix Support--U of M Academic Computing and Networking-
