On 09/26/13 22:53, Sam Varshavchik wrote:
> R Skinner writes:
>
>> On 09/26/13 22:25, Sam Varshavchik wrote:
>> > R Skinner writes:
>> >
>> >>
>> >>> Since you mentioned that you set up your mailboxes on an NFS mount,
>> >>> this is likely the cause. To verify that, configure some mailbox to
>> >>> reside entirely on a local filesystem, and see if it still has this
>> >>> problem.
>> >> What do you mean by more information there? What would I be looking
>> >> for? The rest is basic transactions that have actually worked - as in
>> >> the usual. Or do you mean in the truss? Because I ran several
>> >> transactions and they were the
>> >
>> > truss.
>> I'll give it another look and post up the results then.
The truss results really aren't very encouraging - last time I ran it I
got the same result, but with the log going to stdout as well therefore
the message.
This is the output from `truss -p <pid>`:
select(4,{3},0x0,0x0,0x0) = 1 (0x1)
sigprocmask(SIG_BLOCK,SIGCHLD,0x0) = 0 (0x0)
sigprocmask(SIG_UNBLOCK,SIGCHLD,0x0) = 0 (0x0)
accept(3,{ AF_INET6 [::ffff:192.168.0.100]:25801 },0x7fffffffd398) = 5 (0x5)
fcntl(5,F_SETFD,0x0) = 0 (0x0)
fcntl(5,F_SETFL,0x0) = 0 (0x0)
setsockopt(0x5,0xffff,0x8,0x7fffffffd1b8,0x4,0x801008060) = 0 (0x0)
setsockopt(0x5,0xffff,0x80,0x7fffffffd1a0,0x8,0x801008060) = 0 (0x0)
sigprocmask(SIG_BLOCK,SIGCHLD,0x0) = 0 (0x0)
fork() = 96654 (0x1798e)
close(5) = 0 (0x0)
sigprocmask(SIG_UNBLOCK,SIGCHLD,0x0) = 0 (0x0)
select(4,{3},0x0,0x0,0x0) = 1 (0x1)
sigprocmask(SIG_BLOCK,SIGCHLD,0x0) = 0 (0x0)
sigprocmask(SIG_UNBLOCK,SIGCHLD,0x0) = 0 (0x0)
accept(3,{ AF_INET6 [::ffff:192.168.0.100]:54425 },0x7fffffffd398) = 5 (0x5)
fcntl(5,F_SETFD,0x0) = 0 (0x0)
fcntl(5,F_SETFL,0x0) = 0 (0x0)
setsockopt(0x5,0xffff,0x8,0x7fffffffd1b8,0x4,0x801008060) = 0 (0x0)
setsockopt(0x5,0xffff,0x80,0x7fffffffd1a0,0x8,0x801008060) = 0 (0x0)
sigprocmask(SIG_BLOCK,SIGCHLD,0x0) = 0 (0x0)
fork() = 96658 (0x17992)
close(5) = 0 (0x0)
sigprocmask(SIG_UNBLOCK,SIGCHLD,0x0) = 0 (0x0)
select(4,{3},0x0,0x0,0x0) = 1 (0x1)
sigprocmask(SIG_BLOCK,SIGCHLD,0x0) = 0 (0x0)
sigprocmask(SIG_UNBLOCK,SIGCHLD,0x0) = 0 (0x0)
accept(3,{ AF_INET6 [::ffff:192.168.0.100]:38056 },0x7fffffffd398) = 5 (0x5)
fcntl(5,F_SETFD,0x0) = 0 (0x0)
fcntl(5,F_SETFL,0x0) = 0 (0x0)
setsockopt(0x5,0xffff,0x8,0x7fffffffd1b8,0x4,0x801008060) = 0 (0x0)
setsockopt(0x5,0xffff,0x80,0x7fffffffd1a0,0x8,0x801008060) = 0 (0x0)
sigprocmask(SIG_BLOCK,SIGCHLD,0x0) = 0 (0x0)
fork() = 96661 (0x17995)
close(5) = 0 (0x0)
sigprocmask(SIG_UNBLOCK,SIGCHLD,0x0) = 0 (0x0)
SIGNAL 20 (SIGCHLD)
sigprocmask(SIG_BLOCK,SIGCHLD,0x0) = 0 (0x0)
wait4(0xffffffff,0x7fffffffc80c,0x1,0x0,0x8,0x801008060) = 96661 (0x17995)
wait4(0xffffffff,0x7fffffffc80c,0x1,0x0,0x28,0x801008060) = 0 (0x0)
sigaction(SIGCHLD,{ 0x404e20 SA_RESTART ss_t },{ 0x404e20 SA_RESTART
ss_t }) = 0 (0x0)
sigprocmask(SIG_UNBLOCK,SIGCHLD,0x0) = 0 (0x0)
sigreturn(0x7fffffffc850,0x7fffffffc7f0,0x0,0xfffffe0005c29940,0x28,0x801008060)
= 0 (0x0)
I first went to a folder (from a thunderbird client - although none
other will work either), then to the home folder, then a subfolder and
back - although the connections were exceeded by that time.
>> >
>> >> same across the board, but when I opened that folder it just spat out
>> >> that error.
>> >>
>> >> Moving some boxes is not actually possible now given space issues (It
>> >> is now running on a small ssd drive). But it was working before in
>> >> the exact same configuration with the NFS - that hasn't changed, only
>> >> the courier build
>> >
>> > NFS client/server setup typically has many knobs, of various types,
>> > and configuration settings. Something probably needs tweaking.
>> >
>> Besides having tweaked _everything_, I've tried it with the _exactly_
>> same settings as before - and I do believe that it was exactly the same
>> version of courier as before. I can safely say that the NFS and settings
>> are not the issue. But the courier build.... could there be a knob there
>> I'm not hitting?
>
> No, there are no configuration settings. Like I said, you can narrow
> the problem down to NFS, or something else, by doing a test that uses
> mailboxes on a local filesystem.
I think you may have misunderstood me - I meant build knobs. Given that
the courier builds are compiled from ports, I was thinking that
something may have changed between the installs somewhere (a makefile
option, make variable, etc). Although the answer hasn't been entirely
unhelpful as I would have asked it eventually as well.
------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
_______________________________________________
Courier-imap mailing list
Courier-imap@lists.sourceforge.net
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-imap
