| Summary: | ASTERISK-25966: Database based hints empty during AMI reload or startup | ||||
| Reporter: | Andrew Nagy (tm1000) | Labels: | |||
| Date Opened: | 2016-04-26 18:18:11 | Date Closed: | 2016-05-09 10:13:52 | ||
| Priority: | Major | Regression? | Yes | ||
| Status: | Closed/Complete | Components: | |||
| Versions: | 11.21.2 13.8.1 13.8.2 | Frequency of Occurrence | Constant | ||
| Related Issues: |
| ||||
| Environment: | Attachments: | ||||
| Description: | In asterisk set a DB value:
{code} asterisk -rx 'database put AMPUSER/1000 voicemail default' {code} Now add a hint with a context that references that database value (valid) {code} [xrobau] exten => *999,hint,derp_${DB(AMPUSER/1000/voicemail)} {code} Issue a CLI based reload. {code} [root@freepbxdev1 voicemail]# asterisk -rx 'core show hints' | grep -i derp *999@xrobau : derp_default State:Unavailable Presence:not_set Watchers 0 {code} That is correct! Now issue a reload over AMI only (https://wiki.asterisk.org/wiki/display/AST/Asterisk+13+ManagerAction_Reload) {code} [root@freepbxdev1 voicemail]# asterisk -rx 'core show hints' | grep -i derp *999@xrobau : derp_ State:Unavailable Presence:not_set Watchers 0 {code} This is bad. Seems like it couldn't find the database value after a simple AMI reload. Ok now restart Asterisk. It should pick it up right? {code} [root@freepbxdev1 voicemail]# service asterisk restart Stopping safe_asterisk: [ OK ] Shutting down asterisk: [ OK ] Starting asterisk: [ OK ] [root@freepbxdev1 voicemail]# asterisk -rx 'core show hints' | grep -i derp *999@xrobau : derp_ State:Unavailable Presence:not_set Watchers 0 {code} Still bad. The only way to fix it at this point is issue a CLI reload {code} [root@freepbxdev1 voicemail]# asterisk -rx "core reload" [root@freepbxdev1 voicemail]# asterisk -rx 'core show hints' | grep -i derp *999@xrobau : derp_default State:Unavailable Presence:not_set Watchers 0 {code} In Asterisk 13 the issue surfaces during Startup AND AMI Reload In Asterisk 11 the issue surfaces only during Startup | ||||
| Comments: | By: Asterisk Team (asteriskteam) 2016-04-26 18:18:12.377-0500 Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution. A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report. Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process]. By: Andrew Nagy (tm1000) 2016-04-26 18:26:31.819-0500 Reference ticket (FreePBX): http://issues.freepbx.org/browse/FREEPBX-11223 By: xrobau (xrobau) 2016-04-26 18:43:27.325-0500 Note that doing a 'dialplan reload' alone *does process the hints*. It's as if the dialplan is trying to reload at the same time as the database module, and the database module is returning nothing instead of telling dialplan to wait (.. or the equivalent thereof). However, a simple function DOES work: {code} exten => *998,hint,derp_${IF($[ "X" == "Y" ]?true:false)} {code} As soon as you reference the database, it returns an empty string, without any (apparent) error. By: Andrew Nagy (tm1000) 2016-04-26 18:47:26.863-0500 "dialplan reload" does not work when done over the AMI through the AMI function "Command". The command is successful: Privilege: Command Dialplan reloaded. But the hints are not correctly generated. Only when "dialplan reload" is run over the CLI are they processed correctly. By: George Joseph (gjoseph) 2016-05-03 11:33:12.682-0500 "dialplan reload" over AMI is considered "dangerous" and is disabled by default: From asterisk.conf.sample: {code} ;live_dangerously = no ; Enable the execution of 'dangerous' dialplan ; functions from external sources (AMI, ; etc.) These functions (such as SHELL) are ; considered dangerous because they can allow ; privilege escalation. ; Default no {code} If you set {{live_dangerously = yes}} it should work. Not seeing the update on reload is due to func_db not being loaded before the dialplan. I'm looking into this. By: George Joseph (gjoseph) 2016-05-03 11:50:29.764-0500 Seems to be a simple fix for the original issue... Add {{preload = func_db.so}} to modules.conf. Can you try this and let us know? By: Andrew Nagy (tm1000) 2016-05-03 18:52:06.889-0500 George, 100% works with preload = func_db.so Thanks. Let's resolve if it's ok with you By: George Joseph (gjoseph) 2016-05-04 11:30:41.232-0500 Just FYI.. I'm looking at why the DB function is read restricted. By: Andrew Nagy (tm1000) 2016-05-06 20:37:12.267-0500 Actually I take this back preloading func_db helped during startup however it did not solve the issue on reload. When I issue a reload over AMI the hint is cleared. If I issue asterisk -rx 'core reload' the hint is refreshed (and not cleared which is what I want).. This is probably because DB read is restricted during AMI operations as discussed in the other ticket. By: Joshua C. Colp (jcolp) 2016-05-09 10:13:52.073-0500 That specific issue is being tracked over on ASTERISK-25996 instead. | ||||