| 00:05.37 | *** join/#asterisk-dev jkroon_ (~jkroon@165.16.204.169) |
| 00:22.26 | *** join/#asterisk-dev infobot (ibot@208.53.50.136) |
| 00:22.26 | *** topic/#asterisk-dev is Asterisk Development Discussion -=- http://www.asterisk.org/developers -=- Tier 2 and 3.14159265 support is in #asterisk -=- Check out our blog! blogs.asterisk.org -=- Follow on Twitter at @AsteriskDev |
| 04:00.32 | *** join/#asterisk-dev zopsi (~zopsi@dir.ac) |
| 04:54.51 | *** join/#asterisk-dev ahmed89 (~ahmed89@134.0.214.254) |
| 05:51.17 | *** join/#asterisk-dev tsearle (~tsearle@37.19.10.33) |
| 05:51.17 | *** mode/#asterisk-dev [+o tsearle] by ChanServ |
| 06:18.52 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01:e0a:d:1111:b749:768d:ed77:7c9a) |
| 08:08.16 | *** join/#asterisk-dev ahmed89 (~ahmed89@134.0.214.254) |
| 09:59.30 | *** join/#asterisk-dev ahmed89 (~ahmed89@134.0.214.254) |
| 11:50.57 | tsearle | I might be missing something, but it appears the flag ast_sip_get_ignore_uri_user_options isn't actually used anywhere in the asterisk 13 code |
| 11:53.17 | *** join/#asterisk-dev bford (uid283514@gateway/web/irccloud.com/x-skxwprrzqpvldhyc) |
| 11:53.17 | *** mode/#asterisk-dev [+o bford] by ChanServ |
| 11:56.12 | file | it's used in a macro which is used in places |
| 11:56.26 | tsearle | ok, tried grepping for the macro, but didn't see results |
| 11:56.27 | tsearle | ok |
| 11:56.33 | tsearle | so sanity restored then :D |
| 12:05.23 | tsearle | and just another thing, global flags in pjsip.conf are not also in database(and thus not in alembic) correct? |
| 12:05.43 | *** join/#asterisk-dev pc-m (~pcm@modemcable094.94-70-69.static.videotron.ca) |
| 12:08.07 | file | they could be. |
| 12:08.15 | file | if you mean the global section. |
| 12:12.24 | coreyfarrell | does anyone know if pjsip cli formatter registry should have locking? the container locked at https://github.com/asterisk/asterisk/blob/master/res/res_pjsip/pjsip_cli.c#L329 is allocated without locking. gtjoseph the 'git blame' says you removed locking from that container. |
| 12:22.10 | *** join/#asterisk-dev ahmed89 (~ahmed89@134.0.214.254) |
| 12:43.49 | gtjoseph | coreyfarrell: don't think it needs locking. |
| 13:10.41 | gtjoseph | coreyfarrell: having a few loader issues testing your patch... when I noload res_ari, I get undefined symbol errors from the res_ari_* modules. Shouldn't I get the better message? |
| 13:12.24 | gtjoseph | and maybe this is non related but app_page is supposed to depend on app_configbridge but when I noload app_confbridge, app_page still loads. |
| 13:13.16 | coreyfarrell | that happens because res_ari is not an optional_api module so other modules directly use symbols from res_ari.. so res_ari_* cannot dlopen / we can't see it's AST_MODULE_INFO. |
| 13:13.19 | gtjoseph | so is this patch only applicable when a module can be loaded but declines? |
| 13:13.49 | gtjoseph | hmmmm. yeah. |
| 13:13.53 | coreyfarrell | yes. |
| 13:14.16 | coreyfarrell | about app_page the AST_MODULE_INFO is missing the dependency. |
| 13:14.37 | gtjoseph | ah. it must be only in the <moduleinfo> |
| 13:15.32 | coreyfarrell | I thought I had scanned the menuselect depends but I guess I missed that one. |
| 13:15.45 | gtjoseph | not for this patch but since we lazy load the modules, could we not examine the module_info of a module to determine what it depends on and spit a better messge out if we cant load the parent module? |
| 13:16.44 | gtjoseph | actually what would be cool is a summary dump when the loader finishes of all of the issues. |
| 13:17.06 | gtjoseph | maybe accumulate them in a string container |
| 13:17.31 | gtjoseph | so the last thing you see bedore "Asterisk Ready" is the loader summary. |
| 13:18.08 | file | gtjoseph: yeah I had that thought earlier |
| 13:18.27 | gtjoseph | that would definitely get people's attention. |
| 13:19.33 | coreyfarrell | asterisk 15+ doesn't actually use lazy load. could probably add that back in for a final scanner stage. |
| 13:19.45 | gtjoseph | ah |
| 13:21.10 | gtjoseph | now explain this...why does res_pjsip* depend on res_statsd which is an extended module??? |
| 13:21.47 | gtjoseph | and why doesn't menuselect reflect that? |
| 13:21.49 | coreyfarrell | res_pjsip uses the optional api. if you noload=res_statsd then res_pjsip won't depend on it. |
| 13:22.19 | gtjoseph | holy moly |
| 13:22.30 | gtjoseph | you would know that how? |
| 13:22.44 | file | you wouldn't, which is where confusion sprung in |
| 13:26.01 | gtjoseph | so I just turned off the OPTIONAL_API. shouldn't that have also allowed res_pjsip* to load? |
| 13:27.16 | coreyfarrell | that would make res_pjsip directly depend on res_statsd (not using OPTIONAL_API means that res_pjsip will use res_statsd symbols). |
| 13:27.53 | gtjoseph | oh yeah. another confusing option. :) |
| 13:28.20 | gtjoseph | OPTIONAL_API = MANDATORY |
| 13:28.41 | coreyfarrell | menuselect should probably have <use type="module">res_statsd</use> for res_pjsip - I'm pretty sure that's how we list optional modules for menuselect |
| 13:30.06 | file | that exists in res_pjsip already |
| 13:31.25 | coreyfarrell | ahh your right. gtjoseph said it wasn't listed in menuselect, I hadn't checked it. |
| 13:32.25 | gtjoseph | sorry. what i meant was that if you deselectr res_statsd it doesn't deselect res_pjsip* |
| 13:33.46 | coreyfarrell | technically if OPTIONAL_API is disabled then disabling res_statsd should disable res_pjsip, but with OPTIONAL_API enabled res_pjsip can be compiled without res_statsd. |
| 13:34.53 | coreyfarrell | menuselect can only handle the dependency one way or the other |
| 13:45.43 | coreyfarrell | hmm I had a mixed up branch, looks like 15 does use RTLD_LAZY for modules that export globals. |
| 14:17.18 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-cbuzmztvndugkmbx) |
| 14:17.18 | *** mode/#asterisk-dev [+o kharwell] by ChanServ |
| 14:27.07 | gtjoseph | file: what did you mean "The code which handles the cache update was not changed/altered." ? and yes the cdr and cel sunscriptions work. |
| 14:27.19 | file | gtjoseph: both have code which reacted to cache updates |
| 14:27.39 | file | unless my brain translated channel into bridge |
| 14:27.44 | file | which is entirely possible |
| 14:28.33 | file | it did |
| 14:28.33 | gtjoseph | yeah i only see caching related to channels in cel anyway |
| 14:39.43 | gtjoseph | file: added the comment. |
| 14:54.02 | *** join/#asterisk-dev ahmed89 (~ahmed89@134.0.214.254) |
| 14:54.11 | *** join/#asterisk-dev rmudgett (rmudgett@nat/digium/x-tyjyjtubharlqqgd) |
| 14:54.12 | *** mode/#asterisk-dev [+o rmudgett] by ChanServ |
| 14:57.13 | coreyfarrell | gtjoseph: I'm testing a patch that retries dlopen with RTLD_LAZY then prints missing dependencies. so it only falls back to dlerror() when a module does a &symbol_by_reference from a missing module. |
| 14:58.16 | gtjoseph | Nice! |
| 14:58.17 | *** join/#asterisk-dev ahmed89 (~ahmed89@134.0.214.254) |
| 15:05.20 | coreyfarrell | dlopen errors are not merged like they are for decline errors.. so if you 'noload=res_pjsip.so' it'll print a line per res_pjsip_* with each listing the required modules that are not loaded. |
| 15:19.17 | gtjoseph | coreyfarrell: we were in standup. can we do the string container thing to accumulate the issues and dump them when the loader finishes? |
| 15:20.39 | gtjoseph | we're thinking that we need to get this a little more user friendly before releasing 16 |
| 15:20.54 | gtjoseph | so if i can help, let me know |
| 15:21.01 | file | I can foresee this biting us otherwise >_> |
| 15:44.38 | *** join/#asterisk-dev jameswf (uid27319@gateway/web/irccloud.com/x-psnujhxsrfdpujno) |
| 15:48.59 | *** join/#asterisk-dev pchero (~pchero@87.213.247.82) |
| 16:01.08 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d0034cf19f312a79f11.ipv6.abo.wanadoo.fr) |
| 16:25.54 | coreyfarrell | gtjoseph / file: dlopen and dependency related errors are now delayed until the end of loader.c startup. it's theoretically possibly for other message to be printed between that and 'Asterisk Ready.' but default logger.conf normally doesn't print anything. |
| 16:27.23 | gtjoseph | coreyfarrell: jenkins is complaining about compile issues |
| 16:27.33 | gtjoseph | loader.c:960:4: error: function might be possible candidate for 'gnu_printf' format attribute [-Werror=suggest-attribute=format] |
| 16:27.33 | gtjoseph | <PROTECTED> |
| 16:27.33 | gtjoseph | <PROTECTED> |
| 16:30.22 | coreyfarrell | I had that error then fixed it locally. |
| 16:32.12 | gtjoseph | but did you push the fix up? :) |
| 16:32.57 | coreyfarrell | yes. gerrit is showing the function definition as: static __attribute__((format(printf, 1, 0))) void module_load_error(const char *fmt, ...) { ... } |
| 16:36.43 | coreyfarrell | some other code puts the return type before the __attribute__, I just pushed that to see if it fixes it. my compiler wasn't complaining though (Fedora 28 / gcc 8.1.1). |
| 16:39.37 | coreyfarrell | gtjoseph: I don't know what to do. what version of gcc is being used on jenkins? |
| 16:40.15 | gtjoseph | it's centos 7. give me a sec |
| 16:40.58 | coreyfarrell | OK I'm cloning to a docker / centos 7 |
| 16:45.39 | jameswf | thinks the Jenkins server should be named dan |
| 16:53.31 | rmudgett | file: Has the GVSIP review reached critical mass to be merged yet? |
| 16:55.11 | file | I wish? |
| 16:55.50 | rmudgett | And another thing, would we want to pull the associated pjproject patches to earlier branches so they have the same patches? |
| 16:58.31 | gtjoseph | i would say yes |
| 17:00.27 | coreyfarrell | unless someone has a suggestion I'm going to convert 'module_load_error' to a macro (at this point I think this is a centos 7 compiler bug) |
| 17:02.04 | gtjoseph | really? wow. |
| 17:02.08 | gtjoseph | go for it |
| 17:02.36 | gtjoseph | Ha! |
| 17:02.52 | gtjoseph | oops, wrong chat window :) |
| 17:13.36 | rmudgett | gtjoseph: =-O Oh, no. That was a critical data breach. It let the world know about internal thought processes. |
| 17:14.04 | danjenkins | @jameswf i completely agree |
| 17:14.27 | danjenkins | thinks ive found a bug in 16, really hope not.... |
| 17:15.20 | danjenkins | creating a holding bridge and add an announcer channel, only 1 channel in the bridge and it tells me it cant play media because theres already an announcer in there |
| 17:15.35 | danjenkins | but i do bridge show id |
| 17:15.45 | danjenkins | and ity tells me theres only one channel in there, mine! |
| 17:17.58 | danjenkins | i guess i should go downgrade to 15 or 14 and see eh |
| 17:18.25 | file | we haven't really touched ARI or bridging in that way in 16, so it's certainly possible it occurs in earlier too |
| 17:18.47 | danjenkins | def worked in 13 |
| 17:19.05 | rmudgett | Playback to a bridge uses an announcer channel. If you already have an announcer channel in there you cannot playback. |
| 17:19.13 | rmudgett | and vice versa |
| 17:19.13 | danjenkins | right - but i dont |
| 17:20.05 | danjenkins | i create the bridge, i join the bridge as an announcer and then play back a file |
| 17:20.32 | rmudgett | Your announcer channel plays a file? |
| 17:20.51 | danjenkins | yeah, plays a sound file |
| 17:21.35 | rmudgett | So you stick one end of a local channel into the bridge as an announcer and then make the other end playback? |
| 17:21.58 | rmudgett | That's what the builtin playback is going to do. |
| 17:22.25 | rmudgett | IIRC that builtin playback doesn't remove its channel when done |
| 17:22.35 | danjenkins | oh right |
| 17:22.38 | rmudgett | IIRC it used to. |
| 17:23.02 | danjenkins | ooohhhhh |
| 17:23.04 | danjenkins | yup |
| 17:23.09 | rmudgett | Thought that might be for confbridge |
| 17:23.20 | rmudgett | *Though |
| 17:25.00 | danjenkins | worked it out - i was playing into the bridge not the announcer's channel |
| 17:26.03 | danjenkins | so it was creating a new announcer |
| 17:28.58 | danjenkins | can i stop moh in a holding bridge? or playback silence? |
| 17:29.10 | danjenkins | i dont see any options in creating the bridge to do that.... |
| 17:34.40 | danjenkins | do i really have to playMoh of silence to get rid of the do do dooooo music? |
| 17:44.55 | danjenkins | sorted |
| 18:18.23 | *** join/#asterisk-dev jhord (~jhord@c-73-181-14-245.hsd1.co.comcast.net) |
| 18:19.14 | jhord | I'm currently in the process of adding playlist support to MoH through the use of a helper program. Is there something built-in to asterisk that will read a file line-by-line with proper chunk-boundary handling? |
| 18:31.48 | file | coreyfarrell: if we wanted to return to the previous behavior for the modules which are problematic (statsd / smdi) for the case of a non-existent config file, could we return success? in the past times, even in that scenario things still worked for users fine |
| 18:33.44 | *** join/#asterisk-dev sh_smith (~sh_smith@cpe-76-174-26-91.socal.res.rr.com) |
| 18:33.56 | rmudgett | It might be better to make these problematic optional modules to not decline if their config file is missing. If it is missing then assume the module is disabled. |
| 18:34.05 | file | yeah |
| 18:34.09 | cresl1n | +1 |
| 18:34.49 | cresl1n | We need to try to get this feedback incorporated and merged before/by thursday in preparation for 16.0 release on tuesday of next week |
| 18:38.06 | gtjoseph | coreyfarrell: the dump at the end of the loader looks nice. |
| 18:41.21 | gtjoseph | I would caution against changing actual behavior at this point |
| 18:42.09 | gtjoseph | and concentrate on documentation and logging. |
| 18:47.25 | coreyfarrell | I agree with rmudgett. the optional modules must decline if startup leaves them in an unsafe state, like if initialization fails where calling an exposed API's will crash the system. otherwise we can have them enter a 'running but disabled' state. |
| 18:48.43 | file | the two modules that were presented to me - statsd and smdi - weren't in an unsafe state as a result of that previously |
| 18:49.18 | file | thus what prompted my query |
| 18:50.36 | rmudgett | Those modules may not be in an unsafe state when they declined. However, the loader building the dependency tree cannot assume that. |
| 18:51.06 | file | right |
| 18:51.33 | cresl1n | But the module itself should know best |
| 18:51.39 | cresl1n | which is what I think file is getting to |
| 18:52.22 | coreyfarrell | yes the module should return AST_MODULE_LOAD_SUCCESS if it's safe to use. returning AST_MODULE_LOAD_DECLINE is telling the module loader that the module is not safe to use. |
| 18:52.44 | rmudgett | Though the optional api currently works by registering the api callbacks. As part of a modules initialization it has to do that. If it fails to load it would not be registering the callbacks |
| 18:53.21 | gtjoseph | but should a modules that "uses" another moule fail to load id the other module declines? |
| 18:53.21 | coreyfarrell | not true. the api callbacks are registered with __attribute__((constructor)) function. so the OPTIONAL_API stubs are replaced immediately. |
| 18:53.36 | gtjoseph | or only if it "depends" |
| 18:53.51 | rmudgett | A lot of modules are rather stupid at startup. :) It was a bulk change in return codes that has lead to this situation. |
| 18:54.07 | file | I think not loading if it declines is fine, provided the dependent module is actually in a state where it makes sense to decline |
| 18:54.09 | gtjoseph | no it wasn't |
| 18:55.21 | gtjoseph | well, if pjsip "uses" statsd and statsd isn't there it's fine. so if statsd declines, it should also be fine |
| 18:56.19 | gtjoseph | why should res_pjsip fail to load in once case but not the other? |
| 18:57.41 | file | from a user perspective I agree, from a code perspective I can understand why it can be problematic for the reasons that Corey stated previously |
| 18:57.57 | file | I think if the contract was "in a declined state with optional APIs, it is safe" that'd be nice |
| 18:58.50 | gtjoseph | does it need to be tied to optional apis or can it be tied to "uses"? |
| 18:59.20 | gtjoseph | for instance, res_chan_stats and res_endpoint_stats needs res_statsd |
| 18:59.40 | gtjoseph | rather "depend" on res_statsd |
| 18:59.47 | file | it'd be nice if it were tied to uses |
| 19:00.00 | gtjoseph | yeah |
| 19:00.17 | gtjoseph | which was what i was suggesting earlier. :) |
| 19:05.04 | coreyfarrell | the problem with "in a declined state with optional API it is safe", the only other option is AST_MODULE_LOAD_FAILURE which stops asterisk startup. |
| 19:06.24 | gtjoseph | i was thinking that a LOAD_DISABLED state might be needed at some point |
| 19:06.31 | gtjoseph | but not now |
| 19:06.34 | coreyfarrell | we could always remove the .optional_api = "res_statsd" from the res_pjsip AST_MODULE_INFO, that would make the module loader not enforce anything between the modules (only load priority). or we could make res_statsd stop declining (I think the right choice in this case). I guess we could add a new dependency option '.after' to AST_MODULE_INFO to only enforce ordering of optional modules. |
| 19:07.15 | gtjoseph | in the short term, could we just say that "uses" on a declined module is OK? |
| 19:13.33 | coreyfarrell | you're only talking about optional modules or all dependencies? |
| 19:13.40 | gtjoseph | all |
| 19:14.45 | gtjoseph | there's nothing that tells the load the module provides optional apis is there? |
| 19:14.52 | gtjoseph | loadER |
| 19:15.06 | gtjoseph | can't see anything anyway |
| 19:16.45 | file | Nope |
| 19:18.05 | gtjoseph | so it would have to be a general thing. "depends" is a hard dependency that causes a module to not load if the module it depends on doesn't load. "uses" is a soft dependency that allow a module ot load even if a module it "uses" doesn't load. |
| 19:19.12 | coreyfarrell | we currently have .requires, .enhances and .optional_api. I think it would be reasonable to rename .optional_api to .after which would allow declined modules. |
| 19:19.33 | gtjoseph | but .after means what then? |
| 19:20.29 | coreyfarrell | if res_pjsip had .after = "res_statsd" it would mean that we always try res_statsd before res_pjsip, res_pjsip would hold a reference if res_statsd was running, but would not care if res_statsd declined. |
| 19:21.29 | gtjoseph | ok, i'm getting confused between the MODULEINFO declaration and AST_MODULE_INFO. |
| 19:22.01 | gtjoseph | what exactly does .optional_modules mean now? |
| 19:22.09 | coreyfarrell | struct ast_module_info has doxygen comments in include/asterisk/module.h |
| 19:22.23 | coreyfarrell | optional_api means that if the module is dlopen'ed it must be running. |
| 19:22.38 | gtjoseph | not optional_api, optional_modules. |
| 19:22.48 | coreyfarrell | er sorry yes I meant .optional_modules |
| 19:23.10 | gtjoseph | ok but if it's optional, why require it? |
| 19:23.32 | rmudgett | coreyfarrell: The format error you had earlier. Shouldn't the attribute parameters have been __attribute(format(printf, 1, 2)) rather than 1, 0 ? |
| 19:24.28 | coreyfarrell | rmudgett: hmm maybe. surprised that Fedora gcc didn't throw an error but Centos 7 did. |
| 19:28.27 | gtjoseph | back on topic... can anyone think of a reason that a module that declines should be treated any different than one thaty's not there at all? |
| 19:28.48 | gtjoseph | from a functional perspective that is. |
| 19:31.03 | coreyfarrell | if module_load initializes a global variable in the module and the module has API's which are not NULL safe. |
| 19:31.33 | gtjoseph | but that's an implementation detail. i'm talking from a functional perspective. |
| 19:33.43 | coreyfarrell | how else but LOAD_DECLINE would a module to say "it's not safe to use me"? |
| 19:34.52 | gtjoseph | DECLINE is fine. but if an optional module DECLINEs why should the calling module also decline? |
| 19:35.24 | gtjoseph | if the decliner just wasn't there at all, the caller would continue. |
| 19:35.51 | coreyfarrell | the caller would hit stub functions in the header. if the optional module is there the caller actually calls into the real functions. |
| 19:35.59 | rmudgett | Another thing. If a module declines and you treat it as not there when you fix the problem and then load it. We would need to place that module into the dependency tree at the correct location. |
| 19:36.08 | gtjoseph | ok then, that's what we should fix. |
| 19:36.15 | gtjoseph | (not now) |
| 19:36.53 | coreyfarrell | gtjoseph: sorry which thing should we fix? |
| 19:37.00 | gtjoseph | :) |
| 19:37.26 | gtjoseph | we should make it possible for the following behavior... |
| 19:38.16 | gtjoseph | if module A has module B listed as optional, then whether B declines or isn't there at all A should continue. |
| 19:38.49 | gtjoseph | again, i'm not suggesting this for 16.0. |
| 19:39.41 | jameswf | dependency management (multiple dependency chains) can be a nightmare.... they are why doves cry |
| 19:39.57 | gtjoseph | functionally, whether B declines or isn't there at all makes no difference to A. |
| 19:40.13 | gtjoseph | ...and puppies die. |
| 19:40.16 | gtjoseph | :) |
| 19:41.09 | rmudgett | When B becomes available because why it declined then B needs to go into the correct location of the dependency tree so that B gets unloaded after A |
| 19:41.26 | gtjoseph | good. go m ake that happen. |
| 19:42.10 | rmudgett | This loader stuff is making my head hurt. OR maybe it's lack of sleep :P |
| 19:42.27 | file | Or both |
| 19:42.54 | gtjoseph | you could also say that if B becomes available, then A has to be reloaded in order to use it. |
| 19:42.57 | rmudgett | well, it was an inclusive OR |
| 19:44.09 | rmudgett | Well we could make it so you have to restart Asterisk just like updating the kernel requires a restart. :D |
| 20:03.09 | jhord | Does Asterisk have any file handling routines for reading files line-by-line? I'd prefer to not have to write my own. |
| 20:04.11 | *** join/#asterisk-dev pchero (~pchero@dhcp-077-249-058-090.chello.nl) |
| 20:04.29 | file | don't think so, but if there were it would likely be used in the config loader/parser |
| 20:10.06 | jhord | Thank-you. I'll look around there and see what I can find. |
| 20:12.29 | *** join/#asterisk-dev pchero (~pchero@dhcp-077-249-058-090.chello.nl) |
| 21:20.14 | *** join/#asterisk-dev pchero (~pchero@dhcp-077-249-058-090.chello.nl) |
| 21:36.06 | *** join/#asterisk-dev pchero (~pchero@dhcp-077-249-058-090.chello.nl) |
| 21:48.51 | *** join/#asterisk-dev pchero (~pchero@dhcp-077-249-058-090.chello.nl) |
| 23:24.26 | *** join/#asterisk-dev DivideBy0x0 (~DivideBy0@unaffiliated/divideby0x0) |
| 23:24.26 | *** mode/#asterisk-dev [+o DivideBy0x0] by ChanServ |
| 23:29.31 | *** part/#asterisk-dev kharwell (kharwell@nat/digium/x-cbuzmztvndugkmbx) |