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