Summary: | ASTERISK-11618: Too many open files, asterisk stops responding | ||
Reporter: | Atis Lezdins (atis) | Labels: | |
Date Opened: | 2008-03-11 20:41:52 | Date Closed: | 2008-05-07 08:51:41 |
Priority: | Minor | Regression? | No |
Status: | Closed/Complete | Components: | Core/General |
Versions: | Frequency of Occurrence | ||
Related Issues: | |||
Environment: | Attachments: | ( 0) bt.core.18407.txt.gz ( 1) full_1.txt | |
Description: | I'm testing 1.4.19-rc2, and i noticed that at some point Asterisk stopped delivering queue calls. I was unable to connect with "asterisk -r", so i checked log, and it was full of "Too many open files" (fragment with beginning of that atached). Killed with -11, backtraces attached. | ||
Comments: | By: Tilghman Lesher (tilghman) 2008-03-12 00:52:56 What is the CLI output of "ulimit -n" ? With over 400 threads, you could legitimately have used up all 1024 file descriptors (the default limit) without having a file descriptor leak at all. By: Atis Lezdins (atis) 2008-03-12 04:06:38 It's 1024, however i normally don't have 400 threads - i suspect it's the consequences of using up file descriptors. There are lot of threads that corresponds to manager actions. Anything to look for, to find cause of this? By: Tilghman Lesher (tilghman) 2008-05-07 08:51:41 I recommend using 'ulimit -n' to increase the number of available file descriptors for your process. Unless you can demonstrate otherwise, I see this as you having 400 threads, and you met the limit legitimately, without a leak. |