I posted this on the FreePBX bug tracker but it was confirmed to be an Asterisk issue so have posted it there instead. Unfortunately it has not been picked up yet. As you can see from the latest reply, I could patch it myself but I have no idea on where to start.
This is why I’m posting here, is there anyone out there that can check this out?
This is affecting at least v11.13.1 but as I just spotted it, it could be on earlier versions as well.
Perhaps others can test and confirm that it is an issue and not just me. The bottom line is emails are either not sent, sent to the wrong address or the To is corrupt when a voicemail is in the process of being recorded during a reload. If no reload takes place then everything is fine.
It looks like there is some additional feedback needed on that ticket.
Rusty recommended a post to the dev list and offer a bounty. That seems like solid advice. You are more likely to get an Asterisk Developer on the Asterisk Developers list, the tend to hang out there. Providing a bounty makes it more likely that someone will make your problem their problem.
it’s been just over a week since you posted the bug on the Asterisk tracker. Give them a chance to get to it, bugs can often take several weeks or longer to be addressed as there are many bugs and they need to be properly triaged.
You mentioned that you don’t know how to patch it. Is there a patch being proposed somewhere to address this that I somehow missed as I didn’t see anything in their ticket?
In the mean time, whether for this issue or other issues that can arise, it’s generally not advisable to be reloading the system constantly. I’m not saying that to ‘skirt the issue’ but I am interested (as was James) what is requiring you to reload so often as there may be something you can do to ‘ease the pain’ while waiting for this bug to run its course.
Thank you for the quick replies. I’ve been building a system to replace our legacy PBX. Some legacy features needed to be ported across, such as padlocking. I have spent a fair bit of time coming up with numerous custom scripts however testing these (as I’m not a programmer) has involved changing little bits here and there and slowly testing. This involves a reload every time.
I should really build myself a dummy server and do my testing on that, and once happy port across to the live setup.
I suppose this is once in a blue moon where I’m reloading quite often but with around 200 people still to move across, each one requiring a reload when setting up means that all it takes is for a voicemail to be recording at that moment and it gets sent to the wrong person. It’s just a bit of a worry for me.
What has made things worse is that I had my hand forced last week where the legacy PBX I am trying to move away from had a HDD crash rendering it offline for over a day. I had to move 72 core people as quickly as possible then set up their voicemails etc afterwords, all reloads. This large move of people has shown up other issues with the system that now need ironed out.
As time goes on and things settle the reloads should become less.
As for offering a bounty on the ticket, I’d like to get confirmation from the people out in the forum that this is indeed a bug and not just me. I don’t want to start offering things to end up being told it’s an issue with my system and not Asterisk directly. Can anyone confirm?
as far as if it’s an issue or not, that can take a lot of resources to reproduce. You may want to consider posting a new forum post with a subject header to the effect of: Looking for Someone to Help Confirm a Voicemail Bug, or something like that which may bet someone’s attention.
as far as all the reloads I heard two reasons you mentioned. The adding of 72 users does not imply that you have to reload after each user is entered. You can enter them all and then do a single reload.
as far as your ‘customer scripts’ … it’s still not clear from your answer why you are having to reload each time. You may want to be more specific as someone may be able to provide suggestions as to how to avoid many of these reloads during your testing, though, as you point out, developing on a production system does come with it’s consequences
lastly, I would venture to guess that if this was a widespread problem, there would be more reports of the issue. You may want to try changing to another version of Asterisk to see if the problem persists as having that sort of data added to the bug report can be tremendously helpful in tracking down issues by their dev team.
I know the issue is there so will work round it and will wait to hear back from the bug tracker.
As for the 72 users, I realise a reload can be done at any point however it was all done individually. We didn’t have time to do it all in one go as we were not 100% sure on who we were going to actually move. The way the day went was not pretty. Moving people individually from legacy POTS based digital phones to IP handsets, reconfiguring VLANS, getting the ISDN up and trying to fix the legacy PBX at the same time was just a nightmare. However getting external comms (ISDN) up in under 45minutes was a real boost for the day! - Hats off to the FreePBX team for making it all so easy.
As for the custom scripts, I base most on what I find on the forums and tweak things to suit our needs. I’m therefore adding in extra lines of code which then has the standard typos that only show up when you execute it and find it fails. The change then gets done but a reload is needed for any changes to take effect. When working on a complicated script (I have a few) making little changes all require reloads to become active. However as these things mature it will all settle down. I was pushed into a situation last week that I was not comfortable with and I would not class the system as ‘Fully Ready’ yet.
Maybe this voicemail bug has been around for a while but it’s just with the sheer amount of reloads that I was doing at the time showed it up. A lot of people out there might be none the wiser that it’s a problem. What are the chances of hitting a recording message during a reload…Very slim in most situations and if most companies are like the one I’m at now, the end user very rarely feeds back any problems - It was only a pure fluke that I spotted it myself and started to dig deeper.
No idea on the chances beyond the fact that there are plenty of large busy systems out there that have reloads done while active, so I would say the chances are probably 100% that it happens fairly often. Whether or not anyone detects the problems, if they are happening, who knows.
As far as your scripts, I’ll make two comments. Finding various scripts on the web and trying them out can be very dangerous as there is a lot floating around that is very problematic. (And plenty that is just fine too). But, I still don’t get why you are reloading. You keep mentioning scripts, if these are scripts, as in AGI scripts or manager based scripts, they don’t need reloading. The only time you need to reload is when you need dialplan or other Asterisk configuration file changes to take effect.
If you are editing agi scripts in the module directory, you can just recopy those to the agi directory over the active one, no reload is needed. With that said, if you are editing any stock code, you are going to run into problems for all sorts of reasons including module signing and security warnings starting in FreePBX 12, etc.
The scripts I base from are all from this forum and I do dissect them before running live, it’s just the little comma, close brackets here and there that I often miss. Can’t see the wood for trees sort of situation. I don’t take a straight copy/paste and run it live.
Maybe I’m confusing things by calling them scripts but all are in extension_additional.conf
I’ve never touched AGI scripts and not sure if what I am trying to achieve can be done in this method. Maybe I need to look at this in the future.
I’ll have to bow out after making the last follow-up as I have a pile of work I have to get caught up on. However, if you say you are messing with extensions_additional.conf, that sounds potentially problematic. If you say you are modifying module code that writes to extensions_additional.conf, that’s probably problematic as well and will result in lots of security issues and warnings eventually.
This is an open forum and the fact that they come from this forum does not provide any assurance as to how safe or not they are. If there are things you can’t do that you find you are having to modify in the scripts, you may want to consider starting up forum dialogs to see if these can either be accomplished some ‘supported’ way or otherwise determine if there is need to get change requests in that would benefit others.
For now, best of luck on your endeavors, there are plenty of people around here who should be able to help you.
