Kenneth Murchison writes:
>
>Hmmm... it's run for weeks here on my linux box.
>
>Is idled truely not running, or it just isn't accepting any messages via
>the socket?
The process disappears. I can start it by hand, and it will run
for a while. I can keep a closer watch on it.
>Any messages in
[EMAIL PROTECTED] wrote:
>
> 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 unrelat
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 da
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
> ! signal(SIGALRM, SIG_DFL);
> }
> --- 88,92
> void idle_done(struct mailbox *mailbox)
> {
> /* Remove the polling function */
> ! signal(SIGALRM, SIG_IGN);
In my case (Solaris 8, outlook client) the problem of dying imapds
isn't fixed yet. I think it dies in the second
John Holman wrote:
>
> Ken
>
> Thanks for the quick fix, which has solved the IDLE problem.
No 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 cop
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
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 test
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 mo
(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
10 matches
Mail list logo