| 00:03.06 | jeffg | i think this is kinda on topic... does anybody have one of these http://store.digium.com/productview.php?product_code=8LAPTOPBACKPACK ? |
| 00:03.49 | Qwell | no, they won't give us any :( |
| 00:03.59 | Qwell | bbl |
| 00:06.46 | *** join/#asterisk-dev jmesquita (n=jmesquit@200.170.114.149) |
| 00:12.29 | paravoid | asterisk laptop backpack? |
| 00:12.31 | paravoid | oh my. |
| 00:12.42 | paravoid | sounds very desperate :) |
| 00:17.15 | *** join/#asterisk-dev moy (n=moyhu@189.169.207.127) |
| 00:17.28 | *** join/#asterisk-dev seanbright (n=seanbrig@c-69-251-175-43.hsd1.md.comcast.net) |
| 00:29.56 | *** join/#asterisk-dev seanbright (n=seanbrig@c-69-251-175-43.hsd1.md.comcast.net) |
| 00:38.49 | *** join/#asterisk-dev jeffg (n=jeffg@pdpc/supporter/active/jeffg) |
| 01:15.06 | *** join/#asterisk-dev RoyK (n=roy@ip-96-51-149-91.dialup.ice.no) |
| 01:20.01 | *** join/#asterisk-dev DarkRift (i=dark@bas10-montreal02-1177582556.dsl.bell.ca) |
| 02:19.53 | *** join/#asterisk-dev jcollie (n=jcollie@dsl-ppp239.isunet.net) |
| 02:22.50 | *** join/#asterisk-dev d3wayne (n=deeewayn@76.29.245.9) |
| 02:22.50 | *** mode/#asterisk-dev [+o d3wayne] by ChanServ |
| 03:13.20 | *** join/#asterisk-dev outtolunc (n=me@c-67-174-216-60.hsd1.ca.comcast.net) |
| 03:18.22 | *** join/#asterisk-dev jdg (n=jdg@203.185.180.152) |
| 03:31.24 | *** join/#asterisk-dev jameswf-home (n=james@ip72-204-221-181.ph.ph.cox.net) |
| 03:32.21 | jameswf-home | http://0xcc.net/cdfax/index.html.en heh |
| 03:55.51 | *** join/#asterisk-dev ChanServ (ChanServ@services.) |
| 03:55.51 | *** join/#asterisk-dev outtolunc (n=me@c-67-174-216-60.hsd1.ca.comcast.net) [NETSPLIT VICTIM] |
| 03:55.51 | *** join/#asterisk-dev Mw3 (n=mw3@ip59934bd1.rubicom.hu) [NETSPLIT VICTIM] |
| 03:55.51 | *** join/#asterisk-dev angler (n=angler@pdpc/sponsor/digium/angler) |
| 03:55.52 | *** join/#asterisk-dev corramor (n=corramor@216.207.245.1) [NETSPLIT VICTIM] |
| 03:55.52 | *** join/#asterisk-dev JT (n=j@unaffiliated/jt) [NETSPLIT VICTIM] |
| 03:55.52 | *** join/#asterisk-dev wedhorn (n=wedhorn@dsl-58-6-89-11.act.westnet.com.au) [NETSPLIT VICTIM] |
| 03:55.52 | *** mode/#asterisk-dev [+o ChanServ] by irc.freenode.net |
| 04:18.19 | *** join/#asterisk-dev CunningPike (n=arodgers@S010600095b33697f.vc.shawcable.net) |
| 04:30.08 | JunK-Y | exit |
| 04:35.01 | Corydon76-dig | EAGAIN |
| 04:35.26 | JunK-Y | heheh |
| 04:35.38 | JunK-Y | im going to bed, tty tomorrow |
| 04:35.44 | Corydon76-dig | 'night |
| 04:36.11 | *** join/#asterisk-dev techie (n=techie@adsl-76-214-23-128.dsl.lsan03.sbcglobal.net) |
| 04:36.22 | *** part/#asterisk-dev techie (n=techie@adsl-76-214-23-128.dsl.lsan03.sbcglobal.net) |
| 04:36.38 | JunK-Y | about http://bugs.digium.com/view.php?id=12267 , ive upgraded a system to latest trunk again, it doesnt seems to happen anymore |
| 04:36.47 | JunK-Y | if it doesnt happen this night, i will close it. |
| 04:37.56 | *** join/#asterisk-dev russellb (n=russell@asterisk/developer-and-stable-maintainer/drumkilla) |
| 04:37.56 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 04:38.20 | JunK-Y | its up for 45 minutes, 46 seconds so far |
| 04:38.52 | JunK-Y | 46 active channels |
| 04:38.52 | JunK-Y | 46 active calls |
| 04:38.52 | JunK-Y | 409 calls processed |
| 04:39.13 | JunK-Y | not an heavy load, but if it resists for 10 hours, that will be fine i guest. |
| 05:06.59 | Juggie | JunK-Y! |
| 05:11.17 | *** join/#asterisk-dev IgorG (n=IgorG@195.162.49.23) |
| 06:35.10 | *** join/#asterisk-dev pnlarsson (n=pnlarsso@c83-248-96-159.bredband.comhem.se) |
| 06:45.06 | *** join/#asterisk-dev oej (n=olle@soll4-125.cust.blixtvik.net) |
| 06:45.06 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 06:47.02 | oej | Morning folks |
| 06:47.31 | *** join/#asterisk-dev snuff-work (i=1000@61.29.30.137) |
| 06:47.31 | IgorG | Good day, oej |
| 06:49.09 | *** join/#asterisk-dev obnauticus (n=obnautic@c-67-160-183-109.hsd1.wa.comcast.net) |
| 06:50.56 | oej | All well, IgorG? |
| 06:55.33 | atis_work | good morning |
| 06:55.49 | atis_work | rare to see anybody here at this time :) |
| 06:59.07 | IgorG | well, bugs as always :) |
| 07:00.17 | IgorG | oej: do you remember about sip_notify_auth patch for review? :) |
| 07:00.50 | oej | Too many easter eggs I presume. The old one? |
| 07:33.50 | mvanbaak | oej: the crash in svnmerge when you have the password set in your .svn config is fixed |
| 07:34.04 | oej | Update repotools? |
| 07:37.19 | IgorG | oej: old, May 2007... Issue 9896, already tested my many peoples |
| 07:56.40 | *** join/#asterisk-dev agx (n=AGX@host63-216-static.34-88-b.business.telecomitalia.it) |
| 08:02.54 | oej | IgorG: need to go out, will take a look when I'm back. |
| 08:03.04 | oej | IgorG: Please don't hesitate to poke me. |
| 08:03.27 | IgorG | oej: thank you :) |
| 08:09.25 | *** join/#asterisk-dev tuxd00d (n=tuxd00d@128.187.132.25) |
| 08:13.48 | mvanbaak | oej: yes, it's committed |
| 08:15.34 | tzafrir | wonders where we have versions of udev that are still < 0.54 |
| 08:22.28 | *** join/#asterisk-dev Stian- (n=stian@062016138186.customer.alfanett.no) |
| 08:22.40 | mvanbaak | debian potato ? |
| 08:25.22 | tzafrir | it had udev? |
| 08:26.07 | tzafrir | wonders what happens if two configuration templates have circular inheritance |
| 08:26.31 | tzafrir | [a](b,!) , [b](a,!) |
| 08:26.46 | tzafrir | and someone decides to use one of them |
| 08:28.55 | mvanbaak | oh wait, potato did not have udev |
| 08:29.21 | mvanbaak | I think you have to install it by hand somewhere. but it will be a hard task |
| 08:34.58 | *** join/#asterisk-dev CrashHD (n=CrashHD@76-14-102-131.rk.wavecable.com) |
| 08:46.42 | *** join/#asterisk-dev Drachir (n=kvirc@p57A1BA5B.dip.t-dialin.net) |
| 09:43.40 | *** join/#asterisk-dev ChanServ (ChanServ@services.) |
| 09:43.40 | *** mode/#asterisk-dev [+o ChanServ] by irc.freenode.net |
| 10:00.44 | *** join/#asterisk-dev Zuchmir (n=dddddd@ool-4570ab19.dyn.optonline.net) |
| 10:02.59 | *** join/#asterisk-dev JunK-Y (n=junky@modemcable153.55-201-24.mc.videotron.ca) |
| 10:06.53 | *** join/#asterisk-dev festr_ (n=festr@ns.hiro.cz) |
| 10:06.55 | festr_ | hi |
| 10:08.28 | festr_ | i've crashing scenario in (1.4). eth0(one IP),eth1(no ip),tun0(one ip). when i remove default route and reload asterisk, it crashes at acl.c:188 |
| 10:08.32 | festr_ | <PROTECTED> |
| 10:13.16 | JunK-Y | can you open a bug on bugs.digium.com |
| 10:13.25 | JunK-Y | and attach a backtrace |
| 10:22.06 | tzafrir | hmmm... if I use nethdlc in zaptel.conf to set up a network interface over a zaptel device, |
| 10:22.33 | tzafrir | at which stage am I required to be rootto add the network interface? |
| 10:22.47 | festr_ | JunK-Y: i'm a little bit lazy :) but i will do it. |
| 10:22.53 | tzafrir | Or is root required just to conifgure the network interface? |
| 10:23.53 | JunK-Y | festr_: we're all lazy, dont worry :) |
| 10:25.09 | festr_ | JunK-Y: :) |
| 10:26.01 | festr_ | interesting |
| 10:26.20 | festr_ | asterisk will never start, if there is tun0 device and no default route |
| 10:37.58 | festr_ | http://bugs.digium.com/view.php?id=12300 |
| 10:39.08 | *** join/#asterisk-dev jmls` (n=jmls@mail.tessera.co.uk) |
| 10:46.56 | *** join/#asterisk-dev jeffg (n=jeffg@pdpc/supporter/active/jeffg) |
| 11:08.26 | *** join/#asterisk-dev DagMoller (n=aguirre@unaffiliated/dagmoller) |
| 11:15.52 | *** join/#asterisk-dev _ys (i=yuri@91.151.196.254) |
| 11:22.07 | *** join/#asterisk-dev jeffg (n=jeffg@pdpc/supporter/active/jeffg) |
| 11:35.46 | snuff-home | mm.. what are ppls thoughts on 12301.. i wouldn't have thought bounties should be on the bug tracker |
| 11:54.59 | *** join/#asterisk-dev lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 11:54.59 | *** mode/#asterisk-dev [+o lmadsen] by ChanServ |
| 12:08.32 | *** join/#asterisk-dev caio1982 (i=caio1982@CAcert-br/caio1982) |
| 12:31.01 | oej | Who made a decision about the SNOM call pickup patch? |
| 12:31.57 | lmadsen | you sound like you want to say something about it |
| 12:33.38 | *** join/#asterisk-dev shido6 (n=shido6@204.126.120.132) |
| 12:34.16 | shido6 | im using realtime and deleting messages from mysql, users logging in to check vmail find that the system crashes when the messages are out of order |
| 12:34.28 | shido6 | im looking for a way to reorder the messages |
| 12:34.43 | shido6 | actually.... |
| 12:34.56 | shido6 | when i reorder the messages they are marked as new messages |
| 12:35.09 | shido6 | is there a hidden attribute file somwhere? |
| 12:35.26 | tzafrir | snuff-home, I also wonder if http://www.lobstertech.com/code/voicechanger/ fits the bill :-) |
| 12:35.49 | *** join/#asterisk-dev elguero (n=elguero@ns1.nashuacs.com) |
| 12:36.07 | shido6 | "/var/spool/asterisk/voicemail/context/username/inbox" doesnt have anything in there for all users..... some users do have an attribute file others dont |
| 12:50.41 | *** join/#asterisk-dev jeffg (n=jeffg@pdpc/supporter/active/jeffg) |
| 12:53.09 | oej | lmadsen: Yes, but the bug tracker seems to be referring to a "We" that made the decision. I'm just curious on how decisions are made, can't track it anywhere. |
| 13:05.46 | *** part/#asterisk-dev corramor (n=corramor@216.207.245.1) |
| 13:10.41 | *** join/#asterisk-dev corramor (n=corramor@216.207.245.1) |
| 13:15.24 | festr_ | oej: i'm voting for SNOM, yes i want their pickup patch :) |
| 13:20.36 | oej | festr_: Their pickup patch? I don't think they've made a pickup patch. |
| 13:27.56 | *** join/#asterisk-dev jcollie (n=jcollie@161.210.45.126) |
| 13:40.00 | *** join/#asterisk-dev RoyK (n=roy@ip-96-51-149-91.dialup.ice.no) |
| 13:42.41 | *** join/#asterisk-dev Corydon76-dig (i=eleven@pdpc/supporter/bronze/Corydon76-home) |
| 13:42.41 | *** mode/#asterisk-dev [+o Corydon76-dig] by ChanServ |
| 13:44.08 | *** join/#asterisk-dev putnopvut (n=putnopvu@216.207.245.1) |
| 13:44.08 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 13:57.16 | *** join/#asterisk-dev sruffell (n=sruffell@216.207.245.1) |
| 13:57.16 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 13:59.54 | *** join/#asterisk-dev ctooley (n=ctooley@doc-72-47-33-80.maryville.mo.cebridge.net) |
| 14:00.12 | *** join/#asterisk-dev [T]ank (n=ckwall@206.71.78.158) |
| 14:00.41 | [T]ank | does asterisk agi have a maximum possible thread? Is there a limit to how many connections it can make? |
| 14:06.41 | [T]ank | or are there other things that can randomly make the agi just not respond to php script? |
| 14:06.51 | Corydon76-dig | AGI doesn't, but I've seen a limit on the number of threads that a single process can generate... somewhere around 343... |
| 14:07.07 | Corydon76-dig | concurrent threads |
| 14:07.24 | Corydon76-dig | Could be related to the kernel or amount of memory, though |
| 14:08.00 | [T]ank | what has been happening to me is once in a while for no "apparent" reason, my php scripts will fail to connect to the agi, then the php script will just hang as it tries to complete its connection. asterisk will eventually crash. |
| 14:08.29 | [T]ank | when i look at top, memory and other processes are ok, except for the php script that cannot connect to the agi |
| 14:08.36 | [T]ank | which is getting higher and higher. |
| 14:09.34 | [T]ank | i havent got the slightest clue as to how to debug this or trouble shoot it. It happens once in 3 months or more :-( |
| 14:10.45 | Corydon76-dig | What do you mean, fail to connect to AGI? |
| 14:11.04 | Corydon76-dig | AGI starts scripts, not the other way around |
| 14:11.58 | Corydon76-dig | In any case, this is off-topic in this channel. Try in #asterisk |
| 14:19.28 | mvanbaak | sounds like a bug in the php script |
| 14:23.00 | jsmith | [T]ank: You've turned on "agi debug" and watched the results, right? |
| 14:23.22 | [T]ank | no, but sounds like a good idea ;-) I will do that. |
| 14:23.30 | Juggie | Corydon76-dig, does he mean fast agi? |
| 14:30.54 | *** join/#asterisk-dev anthm (n=anthm@CPE-72-131-113-50.wi.res.rr.com) |
| 14:30.54 | *** mode/#asterisk-dev [+o anthm] by ChanServ |
| 14:32.10 | shido6 | should it matter if voicemessages has messages for a user that are missing numbers..... 2, 5, 15, 25,26,27,50? |
| 14:32.27 | putnopvut | shido6: no that doesn't matter. |
| 14:32.34 | shido6 | ok.... |
| 14:33.22 | lmadsen | jmls: ping? |
| 14:33.48 | lmadsen | open question: was there ever a bug open for func_lock on the bug tracker? I'm trying to find an example of how to use it properly |
| 14:34.12 | Corydon76-dig | shido6: voicemail will get renumbered, if necessary, when another message is left or retrieved |
| 14:34.24 | shido6 | i see |
| 14:34.35 | shido6 | so maybe its jsut my libmyodbc version |
| 14:34.39 | Corydon76-dig | I think we've given up on figuring out why some things won't renumber properly and just accept it now |
| 14:34.57 | Corydon76-dig | shido6: Oh, this is ODBC voicemail? |
| 14:34.59 | shido6 | i've narrowed it down to either the renumber , the mysql-odbc-connector version |
| 14:35.02 | putnopvut | lmadsen: I don't know if anyone has actually ever used func_lock before. |
| 14:35.14 | Corydon76-dig | putnopvut: I tested it |
| 14:35.14 | shido6 | 2000 users |
| 14:35.21 | shido6 | mysql, realtime |
| 14:35.26 | shido6 | tons of dips per user |
| 14:35.31 | shido6 | replies |
| 14:35.33 | shido6 | distribution lists |
| 14:35.37 | lmadsen | putnopvut: ya... I'm going to use it today :) I think jmls was the one who caused it to come to fruition though.... |
| 14:35.44 | shido6 | it all works but crashes intermittently |
| 14:35.49 | shido6 | always at the same spot |
| 14:35.57 | shido6 | but at different times |
| 14:36.04 | shido6 | sometimes in 15 minutes , others after 16 hrs |
| 14:36.12 | Corydon76-dig | shido6: I never trust the libmyodbc packaged with the distro... I always compile from source |
| 14:36.22 | shido6 | thats what im having trouble with..... |
| 14:36.32 | shido6 | compiling it from source with..... --no-gui and thread safe |
| 14:36.42 | shido6 | what version did you compile? |
| 14:36.45 | Corydon76-dig | shido6: Let it install in /usr/local and just change your odbcinst.ini |
| 14:36.48 | shido6 | i tried the latest.... |
| 14:37.34 | shido6 | i'll try the same version but from source..... and leave the 'beta' alone |
| 14:37.41 | Corydon76-dig | Oh, one other thing. We've added a new option in res_odbc in recent versions |
| 14:37.52 | Corydon76-dig | because the mysql reconnect thingy is buggy |
| 14:37.53 | shido6 | what option? |
| 14:38.09 | Corydon76-dig | idlecheck |
| 14:38.10 | shido6 | where can i get this recent version? :) |
| 14:38.19 | Corydon76-dig | It's in 1.4 |
| 14:38.33 | shido6 | im using 1.4.18 |
| 14:38.34 | Corydon76-dig | Set idlecheck in res_odbc to 3600 for each connection |
| 14:38.46 | Corydon76-dig | Should be there, check the sample config |
| 14:39.03 | shido6 | res_odbc.conf.sample |
| 14:39.09 | lmadsen | putnopvut: ya... syntax is listed as: LOCK(<lockname>).... but I'd figure it'd have been Set(LOCK(tryMe)=1) maybe? |
| 14:39.18 | lmadsen | guess I just have to give it a shot and see what happens :) |
| 14:39.27 | Corydon76-dig | lmadsen: Noooo |
| 14:39.44 | Corydon76-dig | Set(diditsucceed=${LOCK(tryme)}) |
| 14:39.45 | lmadsen | plz be to helpin? |
| 14:39.51 | *** part/#asterisk-dev [T]ank (n=ckwall@206.71.78.158) |
| 14:39.51 | lmadsen | ah! |
| 14:40.00 | lmadsen | ok... but how do I set a lock then...? |
| 14:40.02 | shido6 | is a restart required or just a relaod after updating that? |
| 14:40.03 | shido6 | :) |
| 14:40.09 | Corydon76-dig | lmadsen: that sets the lock |
| 14:40.17 | Corydon76-dig | shido6: reload |
| 14:40.26 | shido6 | ok, thank you. |
| 14:40.27 | lmadsen | oic... so I can check then to see if the LOCK was set with that... ok, that makes sense now |
| 14:40.37 | Corydon76-dig | lmadsen: for a single lock, it always succeeds |
| 14:40.38 | lmadsen | thx Corydon76-dig. Helpful as usual :) |
| 14:40.53 | lmadsen | right.. but lets say I tried to set that same lock when it was already set... ? |
| 14:41.00 | Corydon76-dig | lmadsen: for multiple locks, it will succeed, if it can get the lock within 3 seconds |
| 14:41.00 | lmadsen | then that would fail, yes? |
| 14:41.25 | Corydon76-dig | lmadsen: if you're only using 1 lock, it will wait until the lock is available |
| 14:41.56 | lmadsen | gotcha, but fails if it can't get it within 3 seconds... ? (per the note) |
| 14:42.02 | *** join/#asterisk-dev IgorG (n=IgorG@host-90-188-188-119.pppoe.omsknet.ru) |
| 14:42.06 | Corydon76-dig | The name is important that way... you CAN have multiple locks, but it's designed for deadlock avoidance |
| 14:42.23 | lmadsen | ya, I don't want multiple locks with the same name :) |
| 14:43.10 | Corydon76-dig | First level always succeeds, though it may wait... Second level must succeed within 3 seconds, or it fails |
| 14:43.21 | Corydon76-dig | See also TRYLOCK |
| 14:43.26 | lmadsen | ya, I was looking at that one too |
| 14:43.41 | lmadsen | figured I'd be using LOCK(), then TRYLOCK when I want to make sure the other part of the dialplan finished |
| 14:43.50 | Corydon76-dig | You can create some very complex locking sequences with those functions |
| 14:43.56 | lmadsen | however I'm kinda worried this still might not work because this is going to be associated per channel right? |
| 14:44.02 | lmadsen | and not global? |
| 14:44.11 | Corydon76-dig | No, the locks are global |
| 14:44.14 | lmadsen | oh perfect |
| 14:44.19 | Corydon76-dig | and recursive |
| 14:44.25 | lmadsen | recursive? |
| 14:44.35 | Corydon76-dig | You can lock the same lock multiple times |
| 14:44.57 | Corydon76-dig | You just have to unlock that lock the same number of times for it to be available to another channel |
| 14:45.02 | lmadsen | gotcha, makes sense |
| 14:45.06 | lmadsen | thx for the tips good sir |
| 14:45.54 | Corydon76-dig | They work identically to mutexes, with the exception of that 3 second timeout |
| 14:46.05 | *** join/#asterisk-dev moy (n=moyhu@nat/ibm/x-ee8d32a18760c6ab) |
| 14:46.37 | Corydon76-dig | and they're designed to be a better replacement for MacroExclusive |
| 14:46.55 | lmadsen | gotcha... I hadn't even thought about macroExclusive... |
| 14:47.19 | lmadsen | so this 3 second timeout... it basically just waits for up to 3 seconds for the lock to be unlocked, then continues on anyways? |
| 14:47.32 | lmadsen | has a feeling he should find a place to document this stuff... heh |
| 14:47.41 | Corydon76-dig | lmadsen: no, it returns a value to let you know that the lock failed |
| 14:47.53 | Corydon76-dig | lmadsen: see the CLI help |
| 14:47.58 | Corydon76-dig | lmadsen: it's all in there |
| 14:48.20 | shido6 | thank you very much corydon |
| 14:48.22 | lmadsen | well, it's there, but it's not the clearest if you've never dealt with locks before |
| 14:48.25 | shido6 | i'll watch it now... |
| 14:48.33 | lmadsen | now that you've explained this, it makes sense |
| 14:48.35 | lmadsen | thx |
| 14:49.04 | Corydon76-dig | lmadsen: there's a good many functions that are designed directly after their C counterparts |
| 14:49.12 | lmadsen | i don't program in C |
| 14:49.13 | Corydon76-dig | STRFTIME() for example |
| 14:49.44 | Corydon76-dig | and SPRINTF |
| 14:50.21 | Corydon76-dig | LOCK, TRYLOCK, and UNLOCK are the same way |
| 14:50.45 | lmadsen | right, like you mentioned, but since I don't program in C I have no previous concept of them |
| 14:51.25 | Corydon76-dig | Heh |
| 14:51.29 | shido6 | brb |
| 14:56.27 | *** join/#asterisk-dev joetester2 (n=joeteste@216.191.34.13) |
| 15:01.19 | oej | Hm. Just upgraded to 1.4 on a box and it can't find any IAX2 keys... Weird. |
| 15:02.26 | jsmith | oej: By chance are you using an old asterisk.conf file? |
| 15:02.34 | oej | Yep. |
| 15:02.34 | jsmith | oej: Have the keys been initialized? |
| 15:02.43 | jsmith | throws out random ideas |
| 15:02.43 | oej | No need for initialization |
| 15:02.59 | oej | But the asterisk.conf hasn't changed between 1.2 and 1.4 |
| 15:03.07 | jsmith | oej: Sure it has. |
| 15:03.09 | oej | ...but the FreeBSD paths have |
| 15:03.20 | jsmith | oej: There were quite a number of additions to asterisk.conf between 1.2 and 1.4 |
| 15:03.22 | oej | jsmith: Not the pointer to the keys and the rests though |
| 15:03.29 | oej | Yes, additions, but not syntax changes |
| 15:03.55 | jsmith | Just throwing it out as an idea |
| 15:04.05 | oej | I'm grateful... |
| 15:04.16 | oej | Keep throwing |
| 15:05.04 | jsmith | Hmmmn... keys in the wrong format? |
| 15:05.07 | jsmith | Permissions problem? |
| 15:05.11 | oej | share/asterisk |
| 15:05.36 | oej | The makefile has some changes for FreeBSD that seems to override asterisk.conf. Will need to check that |
| 15:07.01 | jsmith | Yeah... if "keys show" doesn't show anything, it's most likely a path problem |
| 15:07.12 | oej | It shows the two standard keys, but not mine |
| 15:07.18 | jsmith | (as Asterisk should come with keys for fwd and iaxtel) |
| 15:07.25 | oej | Seems like something in res_crypto is not following the asterisk.conf setting |
| 15:07.31 | jsmith | Interesting... |
| 15:11.04 | *** join/#asterisk-dev shido6 (n=shido6@204.126.120.132) |
| 15:11.06 | oej | It's configured with "astdatadir" that is *not* documented |
| 15:11.29 | oej | Weird, huh? |
| 15:11.37 | oej | That's something new |
| 15:11.54 | *** join/#asterisk-dev jpeeler (n=jpeeler@216.207.245.1) |
| 15:12.02 | *** join/#asterisk-dev elguero (n=elguero@207.154.34.162) |
| 15:12.12 | oej | Now I got my keys |
| 15:12.38 | oej | Wonder when that was introduced and why? |
| 15:13.07 | JunK-Y | http://pastebin.ca/958159 |
| 15:13.14 | JunK-Y | whatcha think about that? |
| 15:13.35 | JunK-Y | when using optimize and channel lock compiler flags, that stop crashing |
| 15:13.42 | oej | In Asterisk 1.2, AST_KEY is in "astvarlibdir" |
| 15:16.29 | oej | jsmith: And it's not covered in CHANGES... |
| 15:18.02 | oej | This is an issue with 1.4 backwards compatibility... |
| 15:18.29 | jsmith | oej: Yeah... that's the one that always got me... upgrading from 1.2 to 1.4, I had to make sure astvarlibdir was set in asterisk.conf, or no sound files would be found |
| 15:18.41 | jsmith | oej: Hence the reason I asked if you were using an old asterisk.conf file |
| 15:18.43 | oej | astdatadir |
| 15:18.56 | jsmith | oej: But you're right... it should have been both in CHANGES and UPGRADE.txt |
| 15:19.00 | oej | Yes. |
| 15:19.20 | oej | And if it's not set, we should stick with the 1.2 way and use astvarlibdir |
| 15:20.09 | jsmith | You've got my vote on that one |
| 15:20.28 | jsmith | Assuming that 1.4 has been out for 15 months now... |
| 15:20.41 | Corydon76-dig | I'm sure one of the distro maintainers was insistent |
| 15:21.11 | oej | yes, but it still breaks updates and it shouldn't |
| 15:21.27 | JunK-Y | Corydon76-dig: whatcha think about the crash? |
| 15:21.36 | Corydon76-dig | What crash? |
| 15:21.53 | JunK-Y | http://pastebin.ca/958159 |
| 15:22.08 | Corydon76-dig | I think the crash is bad. |
| 15:23.04 | *** join/#asterisk-dev Zuchmir (n=dddddd@ool-4570ab19.dyn.optonline.net) |
| 15:23.05 | JunK-Y | but if i change compiler flag, everything is fine. |
| 15:23.27 | Corydon76-dig | Compiler bug |
| 15:23.33 | Qwell | JunK-Y: like DONT_OPTIMIZE? |
| 15:23.36 | Zuchmir | i messed up a page @ http://www.voip-info.org/wiki/ how do i revert it to how it was |
| 15:23.37 | Qwell | or other things too? |
| 15:23.51 | Qwell | Zuchmir: that is so not a dev question... |
| 15:24.08 | Corydon76-dig | It's not even an Asterisk question |
| 15:24.18 | JunK-Y | Qwell: DONT_OP with DEBUG_CHANNEL_LOCKS |
| 15:24.24 | Zuchmir | quell: where do i ask that q |
| 15:25.09 | codefreeze | Hmmm. I'm torn; 12302 complains that ${EXTEN} is messed up by AEL switch statements. That it is! But how to handle it... that's the rub. Generate code to save & restore ${EXTEN}? Or document it and let users work around it? |
| 15:25.43 | Qwell | codefreeze: that is kinda tricky, considering how the code works |
| 15:25.47 | jsmith | codefreeze: I'd say save and restore |
| 15:26.00 | jsmith | You know, the rule of "least surprise" |
| 15:26.33 | Qwell | the problem, if I understand it, is that the switch statement gets converted to extensions |
| 15:26.46 | codefreeze | yep. |
| 15:27.23 | Qwell | codefreeze: looks like there are two problems there, really. the first problem is the obvious one, with the switch. the second is that it isn't being set back to the original EXTEN outside of the switch |
| 15:28.08 | codefreeze | yep... |
| 15:28.22 | Qwell | sounds like that's going to be a pain to fix |
| 15:28.28 | codefreeze | yep |
| 15:28.32 | codefreeze | lol |
| 15:28.58 | Qwell | good luck! :D |
| 15:29.01 | *** join/#asterisk-dev outtolunc (n=me@adsl-66-218-53-172.dslextreme.com) |
| 15:29.11 | Corydon76-dig | codefreeze: use a substitute variable |
| 15:29.25 | codefreeze | lol -- thanks, Qwell ! |
| 15:29.34 | Corydon76-dig | Translate all uses of EXTEN to ~EXTEN~ |
| 15:29.57 | codefreeze | Corydon76-dig: go on... |
| 15:30.00 | Qwell | or SWITCH_EXTEN, for consistency with macros |
| 15:30.37 | codefreeze | Corydon76-dig: you mean, within switches? |
| 15:30.42 | Corydon76-dig | codefreeze: Then in the initial switch, you do a Set(~EXTEN~=${EXTEN}) and compare in every case to ${~EXTEN~} |
| 15:31.23 | Corydon76-dig | It makes it very clear in the translated code what's happening without using an obscured variable |
| 15:31.41 | Corydon76-dig | like var023 |
| 15:32.48 | JunK-Y | Qwell :i confirm, setting DONT_OPTIMIZE fixes my crash |
| 15:32.55 | Corydon76-dig | and I think that's the only special case that would need that |
| 15:33.08 | Qwell | JunK-Y: yeah, sounds like a compiler problem then.. |
| 15:33.51 | Corydon76-dig | There's no time that ${CONTEXT} would ever be altered, and ${PRIORITY} makes no sense to be using in AEL anyway |
| 15:34.09 | codefreeze | Corydon76-dig: thinking along the same line, but since switches can be in switches, was thinking of saving the EXTEN in a var named after the switch (unique); restoring after exit. |
| 15:34.17 | JunK-Y | time for fill a bug then? |
| 15:34.35 | Corydon76-dig | codefreeze: you can't restore ${EXTEN}, it's an immutable variable |
| 15:35.21 | JunK-Y | a co-worker proposed a tool taht will analyze dialplan and that will generate an optimized modules.conf with all noload => based on what you currently have, whatcha guys think about that? |
| 15:35.57 | Corydon76-dig | codefreeze: oh, you mean restoring the substitute variable... |
| 15:36.17 | codefreeze | no |
| 15:36.28 | jsmith | JunK-Y: It would need to look at more than just extensions.conf |
| 15:36.35 | Corydon76-dig | codefreeze: I'm confused, then |
| 15:36.40 | codefreeze | Junky- not that hard to do, but... will have to be something like a CLI command |
| 15:36.45 | jsmith | JunK-Y: (think about formats, codecs, resources, etc.) |
| 15:36.47 | JunK-Y | jsmith: of course, on all included files. |
| 15:37.19 | JunK-Y | good point jsmith |
| 15:37.32 | JunK-Y | but just to help with apps (which is the most) and functions. |
| 15:37.53 | JunK-Y | codefreeze: a CLI command or a separated tool? |
| 15:39.41 | codefreeze | Corydon76-dig: Well, as I perceive it, I would have to set the subst. var on entry to a switch; then, modify all ${EXTEN} references to ${~EXTEN~} instead (or whatever the var name will be)... right? |
| 15:40.36 | Corydon76-dig | Right |
| 15:41.05 | Corydon76-dig | but you only need to do that once, no matter if you have recursive switches |
| 15:41.40 | Corydon76-dig | because for a recursive switch, ${~EXTEN~} is not altered by a Goto |
| 15:42.37 | Corydon76-dig | (since it's already been converted by the outermost switch) |
| 15:43.58 | Zuchmir | quell: did you look further into #11502 ? |
| 15:44.18 | Corydon76-dig | the only time you might need to do it is for a Gosub, but that's already handled by LOCAL() |
| 15:45.00 | Corydon76-dig | or could be, anyway |
| 15:45.12 | *** join/#asterisk-dev CunningPike (n=arodgers@204.239.12.183) |
| 15:51.55 | *** join/#asterisk-dev miguel3239 (n=elguero@207.154.34.162) |
| 15:52.28 | JunK-Y | http://pastebin.ca/958206 |
| 15:52.46 | *** join/#asterisk-dev ctooley (n=ctooley@doc-72-47-33-80.maryville.mo.cebridge.net) |
| 15:52.54 | JunK-Y | when i tried to run * in valgrind |
| 15:52.57 | codefreeze | JunK-Y: CLI. You don't know the entire dialplan until after it's loaded |
| 15:53.14 | putnopvut | JunK-Y: ouch, valgrind crashed. |
| 15:53.18 | codefreeze | sorry for the delay. Just got a phone call. How unusual! |
| 15:53.53 | JunK-Y | and that cli command would print text to the CLI like: noload => foo.so |
| 15:54.03 | JunK-Y | so user could copy & paste it to their modules.conf? |
| 15:54.49 | codefreeze | JunK-Y: sure |
| 15:56.28 | codefreeze | JunK-Y: I guess we could do this: for each app in the dialplan called, we remove that app entry from the list we build by scanning all the apps... then dump what's left when we are finished... |
| 15:58.23 | codefreeze | Corydon76-dig: well, it's some work trying to determine if a switch is in a switch. Easier just to do the same thing every time we see a switch. |
| 15:59.13 | codefreeze | And, it's not refs to ${EXTEN} just in switches that a affected. It's refs AFTER a switch was traversed. |
| 15:59.57 | JunK-Y | codefreeze: exactly |
| 16:00.45 | JunK-Y | but we have to remove in the list of modules, not in the list of applications. |
| 16:01.41 | codefreeze | JunK-Y: Woa! that's a big difference! The dialplan calls apps, not modules. So we have to have a list of what modules contain what apps. Does that exist somewhere? |
| 16:02.13 | *** join/#asterisk-dev philipp64 (n=chatzill@pool-71-112-38-22.sttlwa.dsl-w.verizon.net) |
| 16:02.51 | JunK-Y | no, but we could the opposite. |
| 16:03.17 | JunK-Y | for example: if MeetMe is called, we know the module is app_meetme.so, so we could simply remove it? |
| 16:04.27 | file | JunK-Y: you are going down a complex path... |
| 16:04.58 | codefreeze | well, if everybody named their mods just so, maybe, but I've seen plenty of exceptions, where you can't easily guess the module name from the app name. |
| 16:05.07 | Corydon76-dig | codefreeze: that's what I'm saying. You don't need to determine if a switch is within a switch, because the outermost switch already does the substitution for everything within, including any embedded switches |
| 16:05.39 | Corydon76-dig | or everything below, really |
| 16:06.11 | Corydon76-dig | So as soon as you see a switch operating on EXTEN, do the substitution for the entire chain of that extension |
| 16:06.12 | JunK-Y | file: any easier way? |
| 16:06.49 | Corydon76-dig | Or rather, everything below that switch |
| 16:07.16 | codefreeze | Corydon76-dig: that's where I'm lost, I guess. A Set() isn't a substitution; it's a save. And matching ${EXTEN} inside expr strings is messy in its own right... |
| 16:07.44 | Corydon76-dig | codefreeze: How so? |
| 16:08.03 | Corydon76-dig | Just substitute "${EXTEN" with "${~EXTEN~" |
| 16:08.14 | file | JunK-Y: well... there is a more complex way... |
| 16:08.35 | JunK-Y | gdb question here: how can i solve issue like: [New Thread 1078655328 (LWP -14400)] |
| 16:08.39 | JunK-Y | Can't attach LWP -14400: No such process |
| 16:08.52 | JunK-Y | (gdb) bt |
| 16:08.53 | JunK-Y | Couldn't get registers: No such process. |
| 16:09.06 | JunK-Y | cause when im running * in gdb, when it dies, ive no infos. |
| 16:09.58 | JunK-Y | file: suggestion for a good implementation? |
| 16:09.58 | codefreeze | Corydon76-dig: ${EXTENSION -> ${~EXTEN~SION |
| 16:10.27 | file | I have no suggestion... it's a path I do not want to think about |
| 16:10.59 | codefreeze | JunK-Y: I just plain don't think there is a table in Asterisk, of which mods contain which apps. |
| 16:11.26 | file | there isn't. |
| 16:11.43 | Corydon76-dig | codefreeze: Well, two substitutions, then... "${EXTEN}" to "${~EXTEN~}" and "${EXTEN:" to "${~EXTEN~:" |
| 16:11.49 | codefreeze | Nor do I think we record in apps, which mod it came from... |
| 16:11.58 | JunK-Y | so such an hash should be made for apps,res,functions,cdr,codec,format correspond to which mod, right? |
| 16:13.08 | codefreeze | JunK-Y: Well, we'd have to maybe record in a structure for apps, funcs, etc, the originating module... somehow. Maybe at registration time. Lotsa changes. Ugly. |
| 16:14.34 | JunK-Y | sounds like a future eventual week-end of coding. |
| 16:14.35 | JunK-Y | :) |
| 16:15.08 | Corydon76-dig | JunK-Y: what is this for, anyway? |
| 16:15.23 | codefreeze | But, if we could, the algorithm would be: a. get a list of all Modules. b. scan dialplan, foreach app call, find assoc module, find that in module list, and mark as used. (c) after dialplan traversed, then output all unmarked modules with "noload" statements. |
| 16:15.54 | Corydon76-dig | What happens if you have an Exec that loads from a database? |
| 16:16.54 | JunK-Y | that will not work, this is just a tool for ppl to help generate a proper modules.conf |
| 16:17.12 | Corydon76-dig | What's wrong with the current modules.conf? |
| 16:17.39 | JunK-Y | everything is loaded. |
| 16:17.45 | Corydon76-dig | So? |
| 16:17.49 | codefreeze | JunK-Y: by proper, you mean "minimally loaded" asterisk |
| 16:17.58 | JunK-Y | that tool will "clean" with proper noload |
| 16:18.02 | JunK-Y | exactly. |
| 16:18.10 | Corydon76-dig | That's a sysadmin decision, best left to the individual sysadmin |
| 16:18.32 | JunK-Y | Corydon76-dig: that tool is exactly to help sysadmin . |
| 16:19.02 | Corydon76-dig | JunK-Y: why don't you create groups within menuselect instead? |
| 16:19.08 | JunK-Y | when having large dialplans, its hard to make decisions about modules.conf, so that tool is just to help you a bit. |
| 16:19.16 | Corydon76-dig | and build dependencies on the groups |
| 16:19.41 | Corydon76-dig | That way, if someone wants to remove a bunch of apps, they can do so in one fell swoop |
| 16:20.04 | codefreeze | Hmmm. By the way, can we put ;; comments inside modules.conf? we should be able to... |
| 16:20.04 | Corydon76-dig | If they want one particular app out of a group, they reselect it, and all is good |
| 16:20.44 | Corydon76-dig | When you come right down to it, if there's a module they will never use, why build and waste disk space, too? |
| 16:21.04 | JunK-Y | Corydon76-dig: you dont think having an association with mods will be good for eventual dev? |
| 16:21.25 | Corydon76-dig | JunK-Y: I don't, actually |
| 16:21.49 | codefreeze | Methinks it might be nice to add how many times a module is referenced as a comment. If something is ref'd just once, it might be a candidate for 'review'. |
| 16:21.55 | JunK-Y | codefreeze: and you? |
| 16:22.07 | Corydon76-dig | although I reserve the right to change my mind in the future, if you come up with a good reason. ;-) |
| 16:22.40 | codefreeze | JunK-Y: Well, I've seen this "wish" maybe 3 times previously, now, by different folks. |
| 16:23.37 | codefreeze | And, because of the dynamic nature of the dialplan, I wouldn't try to not compile certain modules because they currently being used... |
| 16:23.46 | Corydon76-dig | The only thing that might be useful in this regard is things registering their use of configs, so that you can tell Asterisk "Everything that references this config, reload now" |
| 16:24.24 | Corydon76-dig | and you actually can already do that in 1.6, except that the reload isn't there yet |
| 16:24.32 | JunK-Y | i love compile everything, but load only when needed. |
| 16:24.54 | Corydon76-dig | There's a config structure that stores each module that references a particular config file that has been previously loaded |
| 16:25.29 | Corydon76-dig | Actually, I might write that now. |
| 16:25.31 | JunK-Y | ha, the stuff to avoid re-parsing of config files that have not changed? |
| 16:25.38 | Corydon76-dig | JunK-Y: correct |
| 16:26.03 | Corydon76-dig | If you change users.conf, it might be nice to say "Yoohoo! If you reference this file, please reload now." |
| 16:26.37 | Qwell | I don't know if I would force a reload |
| 16:26.44 | Qwell | definitely spew to the CLI though |
| 16:26.53 | Corydon76-dig | but that's the only association I can see that would be useful |
| 16:26.59 | Corydon76-dig | Qwell: I meant a CLI command |
| 16:26.59 | *** join/#asterisk-dev seanbright (i=seanbrig@65.207.74.18) |
| 16:27.07 | Qwell | like reload users.conf? |
| 16:27.11 | Corydon76-dig | Right |
| 16:27.16 | Qwell | neat |
| 16:27.20 | Qwell | I like it |
| 16:27.35 | Qwell | I was thinking you were saying if somebody does a sip reload, and IT saw that users.conf had changed |
| 16:27.41 | Corydon76-dig | Maybe "config reload users.conf" |
| 16:30.11 | Corydon76-dig | Y'know, the people who wanted to tell applications to reload instead of modules... telling config files to reload is one more step and actually makes even more sense |
| 16:30.34 | JunK-Y | lasagna time. |
| 16:32.46 | Qwell | Corydon76-dig: I'd agree with that |
| 16:32.51 | tzafrir | config reload voicemail.conf ? |
| 16:33.22 | tzafrir | but anyway, besides users.conf, does it make sense? |
| 16:34.31 | Qwell | tzafrir: sure, think of a gui |
| 16:35.30 | tzafrir | It means that now every module has to register every config file it works with |
| 16:35.47 | tzafrir | Does extensions.ael count? |
| 16:35.48 | Qwell | they already should |
| 16:36.02 | tzafrir | What about asterisk.conf? |
| 16:36.04 | Qwell | Corydon76-dig did that work already when he was doing the caching |
| 16:36.10 | Qwell | well, okay, most of it |
| 16:38.44 | Zuchmir | quell: did you look further into #11502 ? |
| 16:41.06 | putnopvut | heh, pulling up issue 11502 in the tracker shows a very interesting username for the last note left... |
| 16:42.17 | Qwell | putnopvut: yeah, was a bug when doing reminders |
| 16:57.06 | *** join/#asterisk-dev ctooley (n=ctooley@doc-72-47-33-80.maryville.mo.cebridge.net) |
| 17:01.28 | Juggie | still is a bug |
| 17:01.31 | Juggie | happened to me today] |
| 17:08.50 | Corydon76-dig | tzafrir: you can't reload asterisk.conf. Tried that once already. Doesn't work. |
| 17:11.23 | JunK-Y | wb |
| 17:15.13 | *** join/#asterisk-dev michael-i (n=michael-@Lf40d.l.pppool.de) |
| 17:40.39 | *** join/#asterisk-dev jameswf-home (n=james@dsl093-157-131.phx1.dsl.speakeasy.net) |
| 17:53.04 | *** join/#asterisk-dev fakhir (n=fakhir@unaffiliated/fakhir) |
| 17:57.30 | Qwell | huh |
| 17:57.50 | Qwell | apparently we're doing silence detection on every frame going through the dsp, regardless of whether we want to suppress it or not |
| 17:58.13 | jsmith | Qwell: Uh... that doesn't sound right |
| 17:58.26 | Qwell | even though we don't do anything once we've detected it, unless we're suppressing |
| 18:07.33 | *** join/#asterisk-dev oej (n=olle@soll4-125.cust.blixtvik.net) |
| 18:07.33 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 18:11.04 | *** join/#asterisk-dev joetester2 (n=joeteste@216.191.34.13) |
| 18:13.59 | jpeeler | putnopvut: yeah that's a known issue, i'll take a look at fixing it this weekend |
| 18:31.42 | *** join/#asterisk-dev jmesquita (n=jmesquit@201.7.117.114) |
| 18:33.00 | Corydon76-dig | Heh. I just tried out my "config reload sip_ats.conf" and was surprised to see res_phoneprov getting reloaded |
| 18:33.25 | Corydon76-dig | but now I see res_phoneprov loads sip.conf |
| 18:36.37 | jsmith | Corydon76-dig: sip_ats.conf? |
| 18:36.47 | jsmith | wonders what an "ats" is? |
| 18:36.52 | Corydon76-dig | jsmith: included by sip.conf |
| 18:37.02 | Corydon76-dig | jsmith: my DECT phones |
| 18:37.05 | jsmith | Corydon76-dig: Gotcha... |
| 18:37.18 | Corydon76-dig | I was specifically testing includes |
| 18:37.29 | Corydon76-dig | and it works beautifully |
| 18:39.30 | *** join/#asterisk-dev Deeewayne (n=dwayne@216.207.245.1) |
| 18:39.30 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 18:40.35 | *** join/#asterisk-dev cleone (n=cleo@41.251.87.122) |
| 18:47.09 | shido6 | what happens when 2 ppl leave a message at the same time. |
| 18:47.38 | jsmith | shido6: Each message gets saved to a separate file |
| 18:47.50 | shido6 | Im using mysql , odbc |
| 18:48.06 | Qwell | Corydon76-dig: config list is hot |
| 18:50.00 | *** join/#asterisk-dev kamanashisroy (n=kamanash@202.56.7.138) |
| 18:50.19 | *** part/#asterisk-dev kamanashisroy (n=kamanash@202.56.7.138) |
| 18:50.22 | jsmith | shido6: Then each message should end up as a separate record in ODBC |
| 18:51.06 | tzafrir | So now every module has to assume that users.conf and foo.conf may be reloaded independently? |
| 18:51.13 | shido6 | im reordering on ech vmail access |
| 18:51.26 | shido6 | leaving a message and accessing to retrieve |
| 18:51.47 | shido6 | and added the idletimeout |
| 18:52.19 | tzafrir | At least with chan_zap, it is not exactly possible |
| 19:04.20 | Corydon76-dig | Qwell: I'm currently working on something to make it even better |
| 19:04.43 | Corydon76-dig | AST_LIST_INSERT_SORTALPHA |
| 19:05.40 | Corydon76-dig | tzafrir: Not necessary |
| 19:06.16 | Corydon76-dig | tzafrir: the whole point was that people wanted to reload based upon appname, not module name, so I took it one step further |
| 19:07.00 | Corydon76-dig | Now it reloads based upon config file name, for a logical reason. What do you change? You're not changing the app, you're changing a config file. |
| 19:07.28 | Corydon76-dig | So it makes sense to reload based upon that bit |
| 19:08.24 | bkruse | Corydon76-dig: I agree with that. Though I think in the old convention based on how I learned and time, I think that is a better approach |
| 19:09.05 | Corydon76-dig | bkruse: it's actually dependent on "module reload". It's just a handy alias |
| 19:09.34 | bkruse | Corydon76-dig: Also agreed |
| 19:09.40 | tzafrir | config files seem to me like implementation details rather than logil names. And further more, they are longer names with quite a bit of redundancy |
| 19:10.06 | Corydon76-dig | tzafrir: think from a user perspective, though |
| 19:10.42 | bkruse | exactly |
| 19:10.42 | tzafrir | I do. config files are not something I have to care about. No I will have to care about |
| 19:10.55 | tzafrir | You hammered an implementation detail into the interface |
| 19:11.01 | Corydon76-dig | tzafrir: well, then, don't use the command. ;-) |
| 19:11.16 | tzafrir | What is the alternative? |
| 19:11.27 | Corydon76-dig | "module reload" |
| 19:12.24 | tzafrir | well, just like users.conf, even if I don't use it, it still affects me. Oh well |
| 19:13.27 | Corydon76-dig | Actually, if you don't have a users.conf, it won't let you reload it |
| 19:14.35 | *** part/#asterisk-dev jmls_work (n=jmls@mail.tessera.co.uk) |
| 19:45.15 | *** join/#asterisk-dev anonymouz666 (n=anonymou@201.19.200.110) |
| 19:48.05 | tzafrir | M12160 |
| 19:48.06 | MuffinMan | [new] [Zaptel] General 0012160: [patch] channel alarm set when a channel is opened reported by tzafrir http://bugs.digium.com/view.php?id=12160 |
| 19:48.22 | tzafrir | Will this one be handled in Asterisk? move to Asterisk? |
| 20:03.11 | Corydon76-dig | Who got revision 111111? |
| 20:03.36 | tzanger | heh |
| 20:04.23 | file | automerge |
| 20:04.37 | Corydon76-dig | Lame |
| 20:05.54 | *** join/#asterisk-dev ccesario (n=ccesario@189-19-9-100.dsl.telesp.net.br) |
| 20:06.00 | Qwell | A111111 |
| 20:06.02 | MuffinMan | [111111] Committed by root on 2008-03-26 15:35:19: automerge commit |
| 20:06.47 | tzafrir | At least I managed to snatch zaptel rev. 4000 from the bot |
| 20:25.43 | *** part/#asterisk-dev pnlarsson (n=pnlarsso@c83-248-96-159.bredband.comhem.se) |
| 20:29.03 | paravoid | ilbc removed from the tarball, wooohooo |
| 20:29.29 | paravoid | now, if only the asterisk tarball didn't include by default asterisk-moh-freeplay but downloaded it if selected |
| 20:29.40 | paravoid | also if contrib/firmware was on a different tarball :) |
| 20:30.51 | Qwell | Corydon76-dig: chan_misdn doesn't compile anymore after your config reload thing |
| 20:31.10 | Corydon76-dig | Qwell: yay |
| 20:33.26 | Qwell | will fix.. it's easy |
| 20:36.59 | Qwell | oh, you did :p |
| 20:37.43 | Qwell | funny, that was exactly the code I was writing. character per character |
| 20:38.10 | Qwell | why was that using a define? seems a bit silly, since it was used in all of one place |
| 20:40.23 | Corydon76-dig | exactly |
| 20:51.06 | jmls_home | is confused |
| 20:51.26 | jmls_home | how can I have a process that is 104% cpu on a machine that is 73% idle ?? |
| 20:51.38 | Qwell | 2 CPUs? |
| 20:51.43 | Qwell | /cores |
| 20:52.06 | jmls_home | eek. * is gobbling my cpus |
| 20:52.11 | putnopvut | uh oh |
| 20:52.35 | jmls_home | this isn't right, is it .. |
| 20:52.39 | jmls_home | 13404 root 15 0 66988 26m 7608 S 103 0.8 736:43.61 asterisk |
| 20:53.17 | Corydon76-dig | You can't have 104% cpu |
| 20:53.25 | jmls_home | I do :) |
| 20:53.35 | Corydon76-dig | It's physically impossible. |
| 20:53.56 | jmls_home | http://pastebin.ca/958629 |
| 20:53.59 | putnopvut | Corydon76-dig: top will report more than 100% for a process even though it doesn't really make a lot of sense. |
| 20:54.19 | Corydon76-dig | That would be a failure of top, then |
| 20:54.33 | putnopvut | When russell and I did some g729 tests on galway, we were seeing over 600% CPU from Asterisk when we really loaded it up. |
| 20:54.36 | Corydon76-dig | File a bug! |
| 20:54.49 | putnopvut | It's probably output that way by design... |
| 20:54.58 | Corydon76-dig | Silliness |
| 20:55.14 | Qwell | putnopvut: that's normal, since galway has 8 cores.. |
| 20:55.17 | Corydon76-dig | More likely, someone screwed up the calculation |
| 20:55.25 | putnopvut | Qwell: right, I realize that. |
| 20:55.32 | putnopvut | I'm just arguing with Corydon76-dig because it's fun ;) |
| 20:55.45 | Qwell | :p |
| 20:56.41 | Qwell | jmls_home: do you have 4 cores in that box? |
| 20:56.53 | Qwell | erm, looks like 8 |
| 20:57.27 | jmls_home | how can I tell ? |
| 20:57.31 | Qwell | hit 1 |
| 20:57.33 | jmls_home | is really stupid .. |
| 20:57.36 | Qwell | it'll expand the CPUs |
| 20:57.44 | jmls_home | cooooool |
| 20:57.50 | jmls_home | cpu0-cpu3 |
| 20:58.04 | Qwell | math is a little funky, but it adds up |
| 20:58.23 | Corydon76-dig | cat /proc/cpuinfo |
| 20:58.44 | jmls_home | http://pastebin.ca/958635 |
| 20:59.03 | jmls_home | Intel(R) Xeon(TM) CPU 3.00GHz |
| 20:59.04 | Qwell | that's about what I would've expected to see |
| 20:59.24 | jmls_home | but why is asterisk at 100% .. |
| 20:59.28 | jmls_home | 100%+ |
| 20:59.31 | jmls_home | no calls |
| 21:00.26 | jmls_home | urm, but I do have 2 stuck channels, at the VoiceMailMain() stage |
| 21:01.20 | jmls_home | they wont die with a soft hangup either |
| 21:01.51 | jsmith | jmls_home: Oooh... that's not cool |
| 21:01.58 | jmls_home | nods |
| 21:02.10 | jmls_home | any diagnostics I can run for more info ? |
| 21:02.27 | jmls_home | tries to kill that damned channel |
| 21:03.10 | jsmith | jmls_home: Anything useful from "sip show channel blah"? |
| 21:06.56 | jmls_home | what do you call "useful" ? |
| 21:07.39 | jmls_home | jsmith: http://pastebin.ca/958649 |
| 21:07.41 | jsmith | jmls_home: Information on why it's frozen? |
| 21:08.49 | jsmith | jmls_home: What about the output of "show channel blah" |
| 21:08.58 | jmls_home | http://pastebin.ca/958651 |
| 21:09.07 | jmls_home | was waaaaaay ahead :) |
| 21:10.26 | jsmith | duration 0 |
| 21:10.27 | jsmith | billsec 0 |
| 21:10.30 | jsmith | interesting... |
| 21:11.16 | jmls_home | mm. the other stuck channel has the same |
| 21:12.01 | jmls_home | SVN-branch-1.4-r110727 |
| 21:12.50 | jmls_home | sorry, got to go eat. |
| 21:13.12 | jmls_home | I can leave the box like this for a while tonight if you guys want more info or diagnostics |
| 21:13.19 | jmls_home | has to feed his tummy |
| 21:29.30 | *** join/#asterisk-dev qdk (n=qdk@0x573fe57e.bynqu2.broadband.tele.dk) |
| 21:40.05 | seanbright | hmmmm... |
| 21:40.13 | seanbright | [Mar 26 17:38:28] DEBUG[3723] app_queue.c: Device 'SIP/1129-b7437d10' changed to state '4' (Invalid) but we don't care because they're not a member of any queue. |
| 21:40.30 | seanbright | why is it using the channel name there? |
| 21:44.38 | putnopvut | seanbright: app_queue uses the event system's device state events to learn of device state changes. It reads whatever is in the event IE which corresponds to the device name. |
| 21:44.49 | putnopvut | Er...are you talking about 1.4 or trunk? |
| 21:45.13 | seanbright | 1.4.18 |
| 21:45.45 | putnopvut | interesting...is SIP/1129 supposed to be a queue member? |
| 21:46.03 | seanbright | SIP/1129 is a queue member |
| 21:46.21 | seanbright | this comes in the log right before that last one: |
| 21:46.27 | seanbright | [Mar 26 17:38:28] DEBUG[3723] app_queue.c: Device 'SIP/1129' changed to state '1' (Not in use) |
| 21:47.13 | putnopvut | What does "queue show" say the member's device state is? |
| 21:47.20 | seanbright | not in use |
| 21:47.30 | seanbright | i'm not seeing any problems or anything |
| 21:47.37 | seanbright | just thought the log message was strange |
| 21:48.33 | file | debug messages can be... |
| 21:48.54 | putnopvut | It is strange that device state would pass a full channel name to app_queue. |
| 21:49.00 | putnopvut | Ohhhhh.... |
| 21:49.05 | putnopvut | I know what it is, I think. |
| 21:49.09 | putnopvut | Let me double check to be sure. |
| 21:49.33 | *** join/#asterisk-dev RoyK (n=roy@ip-96-51-149-91.dialup.ice.no) |
| 21:49.40 | putnopvut | seanbright: I figured it out. |
| 21:49.50 | seanbright | putnopvut: sweet. |
| 21:49.59 | putnopvut | apparently, the '-' character is handled a bit odd in __ast_device_state_changed_literal. |
| 21:50.36 | *** part/#asterisk-dev RoyK (n=roy@ip-96-51-149-91.dialup.ice.no) |
| 21:50.37 | putnopvut | It can separate a channel number from its unique id, or it just be valid character in the channel's number. |
| 21:50.58 | seanbright | right |
| 21:51.35 | putnopvut | So if a '-' is encountered, we call device state callbacks with the - and everything afterwards removed AND we call the callbacks with the - and everything after intact. |
| 21:52.34 | putnopvut | Thus, app_queue sees two apparent changes, one with the proper device name, and one with the device name and unique id appended. |
| 21:53.09 | seanbright | gotcha |
| 21:56.56 | *** join/#asterisk-dev TedC (n=cabeen@milli.chem.ucsb.edu) |
| 22:04.13 | *** join/#asterisk-dev callguy (n=chatzill@pool-72-70-89-99.bstnma.east.verizon.net) |
| 22:04.59 | *** part/#asterisk-dev TedC (n=cabeen@milli.chem.ucsb.edu) |
| 22:25.39 | jmls_home | is feeling very full |
| 22:25.45 | jmls_home | *burp* |
| 22:25.49 | jmls_home | sorry, |
| 22:26.06 | *** join/#asterisk-dev sruffell (n=sruffell@216.207.245.1) |
| 22:26.06 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 22:26.11 | jmls_home | right. Any clues on my stuck channels ? I will need to restart * soonish |
| 22:31.37 | jmls_home | *sniff* |
| 22:32.44 | jmls_home | fwiw, this seems to be happening on a daily basis. I had the same problem yesterday. |
| 22:37.52 | *** join/#asterisk-dev jeffg (n=jeffg@pdpc/supporter/active/jeffg) |
| 22:38.36 | jmls_home | I can attach to the process with gdb, but really do not know what to do from there. |
| 22:38.42 | jmls_home | I have done a bt full. http://pastebin.ca/958783 |
| 22:39.08 | jsmith | It obviously above my pay grade |
| 22:39.24 | jmls_home | it's way above my intellect :( |
| 22:40.16 | jsmith | Wow... that was a lot shorter than what I expected to see |
| 22:40.22 | jmls_home | it would just be a shame to not be able to provide any debug info needed before I have to restart it |
| 22:41.28 | Qwell | SO... |
| 22:41.32 | Qwell | what is more important? |
| 22:41.47 | jmls_home | waits for the putdown |
| 22:41.48 | Qwell | having an optimized path for frame copying OR having accurate audio? |
| 22:41.52 | jmls_home | oh |
| 22:41.54 | jmls_home | lol |
| 22:42.16 | jmls_home | both. at the same time... |
| 22:42.28 | Qwell | not possible with the smoother |
| 23:34.58 | Qwell | accuracy won :p |
| 23:35.00 | Qwell | bbl |
| 23:35.19 | lmadsen | lates |
| 23:47.12 | *** join/#asterisk-dev russellb (n=russell@asterisk/developer-and-stable-maintainer/drumkilla) |
| 23:47.12 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 23:48.33 | jmls_home | goes snoozing |
| 23:48.34 | jmls_home | night all |
| 23:50.05 | lmadsen | night |
| 23:50.19 | lmadsen | is only here because he's waiting for a client to call back |
| 23:50.26 | lmadsen | and there he is! |
| 23:57.55 | *** join/#asterisk-dev outtolunc (n=me@c-67-174-216-60.hsd1.ca.comcast.net) |