Open files issues
Scott Likens
damm at yazzy.org
Wed Jan 16 13:10:51 EST 2008
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 at yazzy.org]
> Sent: dinsdag 15 januari 2008 18:49
> To: Alain Spineux
> Cc: Tom Myny; info-cyrus at lists.andrew.cmu.edu
> 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 at tigron.be> 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!
>
>
More information about the Info-cyrus
mailing list