Re: IDLE problem, and unsafe copy command
Ken
Thanks for the quick fix, which has solved the IDLE problem.
I should probably point out though that this fix does not address the
problem I reported last week. It seems to me that under different
circumstances the copy command could still fail in an unsafe way, leading to
loss of messages. (Not that I'm expecting you to be the one to fix it!)
Cheers, John
--
John Holman
Head of Central Servers Team
Queen Mary. Universitly of London
UK
- Original Message -
From: "Ken Murchison" [EMAIL PROTECTED]
To: "John Holman" [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Tuesday, January 16, 2001 4:55 PM
Subject: Re: IDLE problem
John Holman wrote:
(Follow up to last message)
In fact the IDLE problem is quite general. If the client has used the
IDLE
command, it seems that the imapd process will be killed and the
connection
closed with "signalled to death by 14"
whenever more than about 50 seconds passes between commands sent by the
client. Unless I misunderstand something, this shouldn't be happening.
eg
...
4 IDLE
+ go ahead
done
4 OK Completed
wait 50 seconds
server closes imap connection and reports "signalled to death by 14"
John,
Forget about my last message, here is the fix. This was stupid, I don't
know how I missed this. I must have changed the signal disposition at
the last minute without testing it. I apologize for any problems that
this caused. This fix (and a similar one for idle_idled.c) is in CVS
and will be in the next release.
Ken
diff -c -r1.1 -r1.2
*** idle_poll.c 2000/12/14 19:26:48 1.1
--- idle_poll.c 2001/01/16 16:54:26 1.2
***
*** 88,92
void idle_done(struct mailbox *mailbox)
{
/* Remove the polling function */
! signal(SIGALRM, SIG_DFL);
}
--- 88,92
void idle_done(struct mailbox *mailbox)
{
/* Remove the polling function */
! signal(SIGALRM, SIG_IGN);
}
--
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
Re: IDLE problem
Walter Steiner wrote:
In my case (Solaris 8, outlook client) the problem of dying imapds
isn't fixed yet. I think it dies in the second call to idle_poll()
(alarm timer). This might be related to ...
According to the signal(3C) man page on Solaris 8:
void (*signal (int sig, void (*disp)(int)))(int);
If signal() is
used, disp is the address of a signal handler, and sig is
not SIGILL, SIGTRAP, or SIGPWR, the system first sets the
signal's disposition to SIG_DFL before executing the signal
handler.
SIG_DFL remains after idle_poll() is first called by the alarm timer.
Damn! My Linux development system treats unreliable signals as
reliable, so I never caught this glaring error. I just verified that
the current code will NOT work correctly on Solaris 7+ and IRIX 6.x.
Thanks for pointing this out.
There should be at least two ways to fix the problem:
1) add the signal() call in idle_init() to idle_poll() also
idle_update(IDLE_MAILBOX|IDLE_ALERT);
+ signal(SIGALRM, idle_poll);
alarm(idle_period);
2) use sigset() instead of signal() in idle_init() (on Solaris (?, 7, 8))
Is this an appropriate fix? (either one is working for me ... I think,-)
Either solution will work, except Linux apparently doesn't have
sigset(). So I checked in a different fix (below) which uses POSIX
signal sets (to conform with similar code in master.c)
Ken
*** idle_poll.c 2001/01/16 16:54:26 1.2
--- idle_poll.c 2001/01/17 17:26:59
***
*** 40,47
--- 40,50
/* $Id: idle_poll.c,v 1.2 2001/01/16 16:54:26 ken3 Exp $ */
+ #include syslog.h
#include time.h
+ #ifdef HAVE_UNISTD_H
#include unistd.h
+ #endif
#include signal.h
#include "idle.h"
***
*** 75,85
int idle_init(struct mailbox *mailbox, idle_updateproc_t *proc)
{
idle_update = proc;
/* Setup the mailbox polling function to be called at
'idle_period'
seconds from now */
! signal(SIGALRM, idle_poll);
alarm(idle_period);
return 1;
--- 78,100
int idle_init(struct mailbox *mailbox, idle_updateproc_t *proc)
{
+ struct sigaction action;
+
idle_update = proc;
/* Setup the mailbox polling function to be called at
'idle_period'
seconds from now */
! sigemptyset(action.sa_mask);
! action.sa_flags = 0;
! #ifdef SA_RESTART
! action.sa_flags |= SA_RESTART;
! #endif
! action.sa_handler = idle_poll;
! if (sigaction(SIGALRM, action, NULL) 0) {
! syslog(LOG_ERR, "sigaction: %m");
! return 0;
! }
!
alarm(idle_period);
return 1;
--
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
Re: IDLE problem
Kenneth Murchison writes: Damn! My Linux development system treats unreliable signals as reliable, so I never caught this glaring error. I just verified that the current code will NOT work correctly on Solaris 7+ and IRIX 6.x. This may be unrelated, but I notice that idled disappears a day or so after it's started. I get these messages: Jan 3 21:12:50 setup16 master[3226]: [ID 392559 local6.debug] about to exec /usr/local/cyrus/bin/idled Jan 4 09:37:31 setup16 lmtpd[3766]: [ID 840128 local6.error] error sending to idled: 2 This is cyrus-imapd-2.0.9 under Solaris-8. I didn't notice any cores. -- -Gary Mills--Unix Support--U of M Academic Computing and Networking-
IDLE problem
(Follow up to last message) In fact the IDLE problem is quite general. If the client has used the IDLE command, it seems that the imapd process will be killed and the connection closed with "signalled to death by 14" whenever more than about 50 seconds passes between commands sent by the client. Unless I misunderstand something, this shouldn't be happening. eg ... 4 IDLE + go ahead done 4 OK Completed wait 50 seconds server closes imap connection and reports "signalled to death by 14" Thanks, John.. -- John Holman Queen Mary. Universitly of London, UK
Re: IDLE problem
John Holman wrote:
(Follow up to last message)
In fact the IDLE problem is quite general. If the client has used the IDLE
command, it seems that the imapd process will be killed and the connection
closed with "signalled to death by 14"
whenever more than about 50 seconds passes between commands sent by the
client. Unless I misunderstand something, this shouldn't be happening.
eg
...
4 IDLE
+ go ahead
done
4 OK Completed
wait 50 seconds
server closes imap connection and reports "signalled to death by 14"
John,
Forget about my last message, here is the fix. This was stupid, I don't
know how I missed this. I must have changed the signal disposition at
the last minute without testing it. I apologize for any problems that
this caused. This fix (and a similar one for idle_idled.c) is in CVS
and will be in the next release.
Ken
diff -c -r1.1 -r1.2
*** idle_poll.c 2000/12/14 19:26:48 1.1
--- idle_poll.c 2001/01/16 16:54:26 1.2
***
*** 88,92
void idle_done(struct mailbox *mailbox)
{
/* Remove the polling function */
! signal(SIGALRM, SIG_DFL);
}
--- 88,92
void idle_done(struct mailbox *mailbox)
{
/* Remove the polling function */
! signal(SIGALRM, SIG_IGN);
}
--
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
Re: IDLE problem
Cheers Ken,
Thanks for speedy patch.
Regs
Chris
Linux System Admin
Hinterlands Aust.
Ken Murchison wrote:
John,
Forget about my last message, here is the fix. This was stupid, I don't
know how I missed this. I must have changed the signal disposition at
the last minute without testing it. I apologize for any problems that
this caused. This fix (and a similar one for idle_idled.c) is in CVS
and will be in the next release.
Ken
diff -c -r1.1 -r1.2
*** idle_poll.c 2000/12/14 19:26:48 1.1
--- idle_poll.c 2001/01/16 16:54:26 1.2
***
*** 88,92
void idle_done(struct mailbox *mailbox)
{
/* Remove the polling function */
! signal(SIGALRM, SIG_DFL);
}
--- 88,92
void idle_done(struct mailbox *mailbox)
{
/* Remove the polling function */
! signal(SIGALRM, SIG_IGN);
}
--
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
