Hi Tom, I am more concerned with, > 990804:Jan 16 13:39:16 zeus kernel: imapd[32503]: segfault at > d6f556fc eip > 0806fd0a esp bfa06d90 error 5 > 990805:Jan 16 13:39:16 zeus master[24939]: service imaps pid 32503 > in BUSY > state: terminated abnormally the 'Open' file issue would also worry me, but if imapd is segfaulting like this, it may leave a file open? for a time (unsure on this but it seems plausable). Either way the first thing I would be looking at was the eip/esp segfault error. Since that reminds me of a kernel panic of some kind, I would verify with dmesg and see if you can track down what's going on. imo if you fix the eip/esp segfault(kernel panic) you'll fix the open files. Scott On Jan 16, 2008, at 8:57 AM, Tom Myny wrote: > It maybe has not directly anything to see with open files. > > I also see this in my logs: > > 990618:Jan 16 13:39:14 zeus master[32503]: about to exec > /usr/cyrus/bin/imapd > 990636:Jan 16 13:39:14 zeus imaps[32503]: executed > 990650:Jan 16 13:39:15 zeus imaps[32503]: accepted connection > 990671:Jan 16 13:39:15 zeus imaps[32503]: imapd:Loading hard-coded DH > parameters > 990697:Jan 16 13:39:15 zeus imaps[32503]: SSL_accept() incomplete -> > wait > 990708:Jan 16 13:39:15 zeus imaps[32503]: SSL_accept() succeeded -> > done > 990716:Jan 16 13:39:15 zeus imaps[32503]: starttls: TLSv1 with cipher > DHE-RSA-AES256-SHA (256/256 bits reused) no authentication > 990746:Jan 16 13:39:15 zeus imaps[32503]: login: www.someip.net > [192.168.1.1] user1 plain+TLS User logged in > 990747:Jan 16 13:39:15 zeus imaps[32503]: seen_db: user user1 opened > /var/imap/user/a/user1.seen > 990748:Jan 16 13:39:15 zeus imaps[32503]: open: user user1 opened > INBOX > 990796:Jan 16 13:39:16 zeus master[24939]: process 32503 exited, > signaled to > death by 11 > 990804:Jan 16 13:39:16 zeus kernel: imapd[32503]: segfault at > d6f556fc eip > 0806fd0a esp bfa06d90 error 5 > 990805:Jan 16 13:39:16 zeus master[24939]: service imaps pid 32503 > in BUSY > state: terminated abnormally > > Regards, > Tom > > -----Original Message----- > From: Scott Likens [mailto:damm@xxxxxxxxx] > Sent: dinsdag 15 januari 2008 18:49 > To: Alain Spineux > Cc: Tom Myny; info-cyrus@xxxxxxxxxxxxxxxxxxxx > Subject: Re: Open files issues > > Step 1, su - > Step 2, su cyrus - > Step 3, ulimit -a > > More then likely the cyrus user does not have the same ability as > 'root' does for maxfiles, so then you would need to modify them. > Depending on how your Linux configuration is setup that can be just a > simple addition to /etc/profile, or you may need to modify login.conf > or some security file in order to up the maxfiles for that user. > > Since cyrus is not in the 'wheel' group it is not considered a > superuser, so it does not inherit the 'superuser' permissions for > maxopenfiles. > > This is a known thing for like NetBSD, and they fix it appropriately > by telling the script to change the ulimit while it runs... > > hth > > Scott > On Jan 15, 2008, at 7:54 AM, Alain Spineux wrote: > >> On Jan 15, 2008 3:31 PM, Tom Myny <tom.myny@xxxxxxxxx> wrote: >>> Hi Guys, >>> >>> I'm having this each day: >>> >>> Jan 15 09:06:03 zeus lmtpunix[1029]: IOERROR: creating quota file >>> /var/imap/quota/l/user.user1.NEW: Too many open files >>> Jan 15 09:51:29 zeus lmtpunix[24100]: IOERROR: creating quota file >>> /var/imap/quota/i/user.user2.NEW: Too many open files >>> Jan 15 09:51:50 zeus lmtpunix[24100]: IOERROR: opening quota file >>> /var/imap/quota/f/user.user3: Too many open files >>> Jan 15 09:52:01 zeus lmtpunix[24100]: IOERROR: opening quota file >>> /var/imap/quota/i/user.user4: Too many open files >>> Jan 15 10:34:04 zeus lmtpunix[16510]: IOERROR: creating quota file >>> /var/imap/quota/w/user.user5.NEW: Too many open files >>> .. >>> >> >> Are you sure cyrus is guilty and no simply suffering of another >> process ? >> You can use lsof command to see who open what. >> >>> I've tried the following: >>> >>> --- >>> >>> Check file-max: >>> >>> cat /proc/sys/fs/file-max >>> >>> 359801 >>> >>> --- >>> >>> Checking ulimit: >>> >>> ulimit -a >>> core file size (blocks, -c) 0 >>> data seg size (kbytes, -d) unlimited >>> max nice (-e) 0 >>> file size (blocks, -f) unlimited >>> pending signals (-i) unlimited >>> max locked memory (kbytes, -l) unlimited >>> max memory size (kbytes, -m) unlimited >>> open files (-n) 1024 >>> pipe size (512 bytes, -p) 8 >>> POSIX message queues (bytes, -q) unlimited >>> max rt priority (-r) 0 >>> stack size (kbytes, -s) 8192 >>> cpu time (seconds, -t) unlimited >>> max user processes (-u) unlimited >>> virtual memory (kbytes, -v) unlimited >>> file locks (-x) unlimited >>> >>> Set ulimit -n 10000 on start-up script -> No effect :( >>> >>> >>> --- >>> >>> Changed NR_OPEN and NR_FILE in kernel, recompile -> No effect :( >>> >>> --- >>> >>> >>> Anybody an idea ? >>> >>> Regards, >>> Tom >>> >>> ---- >>> Cyrus Home Page: http://cyrusimap.web.cmu.edu/ >>> Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki >>> List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html >>> >> >> >> >> -- >> Alain Spineux >> aspineux gmail com >> May the sources be with you >> ---- >> Cyrus Home Page: http://cyrusimap.web.cmu.edu/ >> Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki >> List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html >> >> >> >> >> > > > > > !DSPAM:478e477465121804284693! > > ---- Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
