| 00:13.49 | *** part/#asterisk-dev rgagnon (~rgagnon@rrcs-71-42-183-54.sw.biz.rr.com) |
| 00:40.26 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 00:40.26 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 02:52.59 | *** join/#asterisk-dev serafie (~erin@24.214.158.242) |
| 05:23.37 | *** join/#asterisk-dev oej (~Adium@LMontsouris-156-26-11-32.w80-14.abo.wanadoo.fr) |
| 05:23.42 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 06:34.24 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-84-109-18-138.red.bezeqint.net) |
| 06:34.24 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 07:17.10 | *** join/#asterisk-dev oej (~Adium@ANice-652-1-289-69.w86-203.abo.wanadoo.fr) |
| 07:17.10 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 08:04.54 | *** join/#asterisk-dev oej (~Adium@ANice-652-1-289-69.w86-203.abo.wanadoo.fr) |
| 08:04.54 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 12:17.02 | *** join/#asterisk-dev w9sh (~sph@50-79-224-193-static.hfc.comcastbusiness.net) |
| 12:42.36 | *** join/#asterisk-dev oej (~Adium@ANice-652-1-289-69.w86-203.abo.wanadoo.fr) |
| 12:42.36 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 13:34.30 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-84-109-18-138.red.bezeqint.net) |
| 13:34.30 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 13:55.37 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 13:55.38 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 14:25.03 | *** join/#asterisk-dev serafie (~erin@24.214.158.242) |
| 17:54.33 | *** join/#asterisk-dev tzafrir (~tzafrir@212.179.75.202) |
| 17:54.33 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 18:04.26 | *** join/#asterisk-dev oej (~Adium@ANice-652-1-2-117.w86-193.abo.wanadoo.fr) |
| 18:04.26 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 19:09.48 | Kobaz | weird |
| 19:09.50 | Kobaz | it happened again |
| 19:09.58 | Kobaz | manager stopped running while asterisk was still running |
| 19:19.44 | coreyf1513 | Kobaz: what version of asterisk? |
| 19:21.30 | Kobaz | 1.8.12 |
| 19:22.32 | coreyf1513 | when it happens done netstat show asterisk listening to 5038? |
| 19:22.41 | Kobaz | nope |
| 19:22.43 | Kobaz | all gone |
| 19:23.11 | Kobaz | # netstat -lntup | grep 5038 |
| 19:23.12 | Kobaz | # |
| 19:24.13 | coreyf1513 | hmmm so it's actually closing the listener.. that's probably good news |
| 19:24.22 | Kobaz | good news? |
| 19:24.23 | Kobaz | heh |
| 19:24.28 | coreyf1513 | if it wasn't closed I would suspect a dead lock which would be harder to find |
| 19:24.55 | Kobaz | ah.. it wasn't deadlocked |
| 19:25.08 | Kobaz | this happened twice so far when i restarted my agi daemon |
| 19:25.15 | Kobaz | closed off like 5 manager connections |
| 19:25.22 | coreyf1513 | agi? you mean ami? |
| 19:25.29 | Kobaz | agi/ami both |
| 19:25.37 | Kobaz | i have children that connect to ami |
| 19:25.55 | Kobaz | so 5 manager connections close, and then ami is unavailable |
| 19:26.13 | Kobaz | it's almost like the ami goes along and says, oh my clients are gone, i can close my server socket |
| 19:26.46 | coreyf1513 | ok i'm grabbing that version from svn going to take a quick look |
| 19:27.02 | Kobaz | but it doeesnt happen every single time |
| 19:27.03 | Kobaz | but that |
| 19:27.07 | Kobaz | 's the trigger |
| 19:28.34 | Kobaz | where is the ami listen server started up? |
| 19:30.35 | coreyf1513 | manager.c, end of __init_manager() |
| 19:40.30 | coreyf1513 | maybe you are running out of resources? i don't see anything in manager.c that could do this (only reload touches the listener). tcptls.c has ast_tcptls_server_root(), this kills the listener if it fails to allocate memory/thread for a connection |
| 19:42.58 | coreyf1513 | sorry 1.8.12 only killed the server if the thread failed, dropped connection on allocation failure.. if that happened you should have a warning in your logs |
| 19:45.42 | Kobaz | no warnings |
| 19:46.39 | Kobaz | what type of resources? |
| 19:46.59 | Kobaz | i have 2.5 gigs of ram free, and 4200 open files |
| 19:49.34 | coreyf1513 | other than memory/files not sure... check ast_pthread_create_detached_background and it's syscalls, anything that causes that procedure to fail will shutdown the listener |
| 19:51.31 | coreyf1513 | it also seems strange that the asterisk would recover from lack of resources without needing to restart the whole process.. sorry i'm not as much help as I hoped... |
| 19:52.50 | Kobaz | yeah it's pretty easy to recovery |
| 19:52.52 | Kobaz | recover |
| 19:55.13 | coreyf1513 | i just looked closer, the tcptls.c procedure I was looking at would close the client connection not the server |
| 19:58.18 | Kobaz | mm |
| 19:58.57 | Kobaz | in other news... |
| 19:59.00 | Kobaz | /usr/include/linux/types.h:13:2: warning: #warning "Attempt to use kernel headers from user space, see http://kernelnewbies.org/KernelHeaders" [-Wcpp] |
| 19:59.05 | Kobaz | getting a lot of those in asterisk 11 |
| 19:59.22 | Kobaz | for: #include <signal.h> |
| 19:59.41 | Kobaz | er i mean |
| 19:59.44 | Kobaz | #include <sys/signal.h> |
| 19:59.46 | Kobaz | that one |
| 19:59.52 | coreyf1513 | the only other suggestions i can give is try latest 1.8, or try testing with DEBUG_FD_LEAKS, maybe extend to allow output of a backtrace on certain fd closes |
| 20:03.30 | coreyf1513 | Kobaz: I think that's a problem with your system headers... gcc, libc and/or kernel headers doing something they shouldn't |
| 20:04.30 | Kobaz | mm |
| 20:15.12 | coreyf1513 | just a warning about the compile options, DEBUG_THREADS leaks memory... I haven't noticed an issue with DEBUG_FD_LEAKS |
| 20:15.44 | Kobaz | oh |
| 20:15.46 | Kobaz | fun |
| 20:15.57 | Kobaz | is that why my asterisk uses 2 gigs of ram with no active channels |
| 20:16.01 | coreyf1513 | i'm working on some patches |
| 20:16.57 | coreyf1513 | fixing the DEBUG_THREADS leaks will not make it "lean". DEBUG_THREADS uses 3k for each mutex |
| 20:17.19 | Kobaz | there used to be VERBOSITY_ATLEAST |
| 20:17.24 | Kobaz | what's the new way? |
| 20:17.51 | coreyf1513 | sorry i'm not sure what your talking about |
| 20:18.17 | Kobaz | there used to be a macro for that in 1.8.. it's gone in 11 |
| 20:20.05 | Kobaz | #define VERBOSITY_ATLEAST(level) (option_verbose >= (level) || (ast_opt_verb_module && ast_verbose_get_by_module(AST_MODULE) >= (level))) |
| 20:20.12 | Kobaz | well i can put it back for now |
| 20:20.54 | coreyf1513 | DEBUG_THREADS adds a bunch of code to mutex handling (ie for dead-lock debugging).. this is different from verbose levels.. |
| 20:21.06 | Kobaz | yeah i know |
| 20:21.11 | Kobaz | i'm just working on my patches here |
| 20:21.26 | Kobaz | had a problem with porting some stuff from 1.8 to 11 since a macro was gone |
| 20:24.58 | coreyf1513 | i think that might be gone because the console verbose level isn't tied to logger verbose anymore |
| 20:25.33 | Kobaz | yeah i was just thinking that |
| 20:52.55 | *** join/#asterisk-dev oej (~Adium@LMontsouris-156-26-11-32.w80-14.abo.wanadoo.fr) |
| 20:52.55 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 21:22.38 | Kobaz | wow |
| 21:22.39 | Kobaz | crazy |
| 21:22.42 | Kobaz | it compiled |
| 21:45.37 | leifmadsen | woah |
| 21:45.41 | leifmadsen | I did not see that coming |
| 21:45.52 | leifmadsen | and the pie throwing contest did not either |
| 21:46.10 | Kobaz | heh |
| 21:46.11 | Kobaz | what? |
| 21:49.46 | leifmadsen | nevermind :) |
| 21:55.12 | Kobaz | make -j still fails rather badly in 11 |
| 22:18.38 | Kobaz | this is fun |
| 22:18.41 | Kobaz | i get to play with 11 now |
| 22:19.47 | Kobaz | here goes |
| 22:20.04 | Kobaz | oo it started |
| 22:40.50 | Kobaz | aaaaand it crashed |
| 23:04.10 | Kobaz | k that was my bug, do de do |