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
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,
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
(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
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 pass
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
