Summary: | ASTERISK-25524: module reload res_calendar.so does not reload everything in calendar.conf | ||
Reporter: | Jesper (ib2) | Labels: | calendar patch |
Date Opened: | 2015-11-05 06:42:55.000-0600 | Date Closed: | 2017-09-19 06:48:57 |
Priority: | Minor | Regression? | |
Status: | Closed/Complete | Components: | Resources/res_calendar |
Versions: | 11.18.0 13.6.0 | Frequency of Occurrence | Constant |
Related Issues: | |||
Environment: | CentOS 6.7 | Attachments: | ( 0) calendar_reload.patch |
Description: | if the url is changed from:
url = https://www.google.com/calendar/ical/XXXXXXXXX/public/basic.ics to url = http://www.google.com/calendar/ical/XXXXXXXXX/public/basic.ics changes are not active after "module reload res_calendar.so" calendar.conf in use: {noformat} [gcal1] type = ical url = https://www.google.com/calendar/ical/XXXXXXXXX/public/basic.ics user = secret = refresh = 5 timeframe = 60 {noformat} similar if {noformat} channel = SIP/joe {noformat} is set in calendar.conf and then the line "channel = SIP/joe" is removed from the config, the setting for the variable is not updated after "module reload res_calendar.so" I have to do a: /usr/sbin/asterisk -rx "module unload res_calendar_icalendar.so" ; sleep 2 ; /usr/sbin/asterisk -rx "module load res_calendar_icalendar.so" to make changes effective | ||
Comments: | By: Asterisk Team (asteriskteam) 2015-11-05 06:42:56.076-0600 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: Marek Cervenka (cervajs) 2015-11-11 09:13:26.176-0600 same problem on asterisk 13.6.0 By: Martin Tomec (matesstar) 2016-12-28 10:51:39.628-0600 Partially solved in issue ASTERISK-26422, but the patch seems to be wrong (or at least not complete) By: Martin Tomec (matesstar) 2016-12-30 07:52:45.243-0600 As a workaround, you can use patch from ASTERISK-26422 and ASTERISK-26683 and then set to all calendars "fetch_again_at_reload = yes" Or you can use attached patch, which has "fetch_again_at_reload" turned on by default. By: Friendly Automation (friendly-automation) 2017-09-19 06:48:58.883-0500 Change 6508 merged by Joshua Colp: res_calendar: On reload, update all configuration [https://gerrit.asterisk.org/6508|https://gerrit.asterisk.org/6508] By: Friendly Automation (friendly-automation) 2017-09-19 07:35:11.034-0500 Change 6507 merged by Joshua Colp: res_calendar: On reload, update all configuration [https://gerrit.asterisk.org/6507|https://gerrit.asterisk.org/6507] By: Friendly Automation (friendly-automation) 2017-09-20 07:01:17.184-0500 Change 6509 merged by Jenkins2: res_calendar: Plug memory leak and micro-optimization [https://gerrit.asterisk.org/6509|https://gerrit.asterisk.org/6509] By: Friendly Automation (friendly-automation) 2017-09-20 09:47:06.965-0500 Change 6510 merged by Joshua Colp: res_calendar: Plug memory leak and micro-optimization [https://gerrit.asterisk.org/6510|https://gerrit.asterisk.org/6510] |