I recently migrated us from AsteriskNOW 1.7 w/ FreePBX 2.9 Asterisk 1.8 to PBX In a Flash Purple w/ Asterisk 1.8 + FreePBX 2.9. I had no option to use the regular FreePBX since the tar ball has been removed from mirror.freepbx.org.
Things seemed great during testing, but when we deployed, all the calls would drop every 45 minutes or so give or take. There was no clear reason as to why, or an exact time in-between call drops. I saw as many as 20 Simultaneous calls going on, and had over 30 users logged into the system.
We had to roll back to the old system since we really had no idea how to debug this, its hard to use “logic/process of elimination” when there doesn’t seem to be an exact cause, and after it dropped, it would start to work perfectly afterwards for X amount of time.
Any suggestions?
My thoughts were somehow that it was PBX in a flash fault, or possibly something to do with our Integrated NIC? but I really have no idea…
Well I’m trying to get there, but Its been difficult… The plan was to get to PBX in a flash based on CentOS 6 so we could upgrade to FreePBX 12 then jump to the FreePBX Distro.
My main concern with this is being able to roll back the database, and perhaps I’m being overly cautious.
I was under the impression that FreePBX manipulates the DB during upgrades, so that if we were to put a server live with newer software, then need to roll back, we wouldn’t be able to just dump the DB and move it back to the old system.
If its not the case, as my boss suggested after this fiascal last week, we could try to just jump to the latest and greatest, and then move back if it doesnt work. Losing a days worth of CDR records and such is not an option. If we “lost” the “Asterisk” DB, thats not huge really, its mostly the CDR/Voicemail/Call Recordings that need to be preserved if we have to roll backwards.
Do I “need” to be on PBX In a flash or Elastix to use the tool? What about AsteriskNOW 1.7 w/ FreePBX 2.9 then just go straight to FreePBX 10 or SNG7?
Still wish I had an idea of how to troubleshoot this, what things I could look for. Really hard for me to diagnose random all calls dropping… @tonyclewis@lgaetz
All I see seems to be endless lines of Jan 18 13:04:40 node1 asterisk[3753]: rc_avpair_new: unknown attribute 1490026597 so perhaps that was the cause?.. Well starting fresh again, so fingers crossed that the problem doesn’t follow me.
I found what looks to be the culprit, and at least a better direction of “what to look for” (I Think, I also think this would have been a better question for Asterisk Forums, sorry, I’m never sure where to post)
root@node1:/var/log $ grep segfault /var/log/messages*
/var/log/messages:Jan 18 12:28:03 node1 kernel: asterisk[29006]: segfault at 38 ip 000000399f467a0a sp 00007f19b1466c50 error 4 in libc-2.12.so[399f400000+18a000]
/var/log/messages:Jan 18 12:59:47 node1 kernel: asterisk[6782]: segfault at 7fd6826c7bb8 ip 000000399f476055 sp 00007fd6071e3ce0 error 4 in libc-2.12.so[399f400000+18a000]
/var/log/messages:Jan 18 13:19:33 node1 kernel: asterisk[15436]: segfault at 77 ip 00007fe8a8806cb0 sp 00007fe82cf040e0 error 4 in libsqlite.so.0.8.6[7fe8a87ec000+4b000]
As stated, I am trying to get to a newer version, but since you cant migrate from FreePBX version to a new version, or goal is to migrate to a system running the same version, then upgrade FreePBX once its confirmed working. BUT, since FreePBX takes down tgz files, I was forced to use 3rd party PBX In a Flash.
I’m not sure if you realize how many old PBX systems there are sitting in closets and it would really help to keep old files available for long time so that this could be avoided. We want to avoid running updates on a known working system and rebuild the system on CentOS 6.
@lgaetz The issue isn’t AsteriskNOW, the issue is rebuilding the sytem w/ FreePBX 2.9. I have AsteriskNOW 1.7, but its based of CentOS 5, we want to get to CentOS 6 w/ FreePBX 2.9.
Also, the script linked above, if we have to roll back, which we already did once, we wouldn’t be able to, since its a “one way trip”. This is why we want to rebuild with the same version of FreePBX, so we can go backwards via Backup/Restore if needed.
Did you not look at that link and script. It’s not a 1 way thing. You take a new box and install FreePBX Distro 10.13.66 and then run that script. That scripts goes into your existing system and gets all the data and converts it onto the new system without every harming or touching anything on the old system or even taking it down.
@tonyclewisI have done more then look at the script, I have executed it, and it seemed to work well. But again, if it goes into production and things start failing, like they did already, we want to be able to roll back all the databases backwards to the old system. I was under the impression that FreePBX Manipulates the databases during upgrades, and you shouldn’t just go migrating a Database from FreePBX Distro 10 to AsteriskNOW v 1.7. But I did mention, if its just the “asterisk” db, thats not a huge deal, does the CDR database stay the same?
@lgaetz No I don’t think it did, I have looked. I was just more hoping to find the TGZ file and hand compile, seemed to be the “best” option, but we have resigned to upgrading FreePBX on the known working system, to get to a version of FreePBX that is in an official Distro. That way we can “move backwards and forwards” as needed. I was actually able to get FreePBX 12 on CentOS 5 via atomic repo for PHP v 5.4. So well just take the leap that nothing breaks, not the way we wanted, but we tried the way we wanted and it didn’t work :P. I certainly don’t blame FreePBX for PBX In a Flash script on CentOS 6 not working, especially when the script was created years ago and the repo’s have changed. I’m hoping that the FreePBX Distro will resolve the Asterisk Crash problems.
No you can’t roll back. But why would you. Point of this script is if you have issues go back to the untouched original machine. You are making this more complicated then it needs to be. Bring up a new machine and use the migration script. You should not have problems. If so post any issues here. Again until you are on Fpbx 13 and asterisk 11 or 13 nobody is going to offer much assistance on troubleahooting a 6 year old version of software.
@tonyclewis The reason to roll back is we can’t lose CDR records. Its like 911 saying they don’t have a record of your call due to phone maintenance. Its just not acceptable. Upgrading is not more important then losing CDR records when everything works fine as is. I’m just trying to avoid the inevitable HD/MoBo Failure. Its nice to know that im SOL because the previous person didn’t upgrade our PBX, so I come to the forum and just get told, sorry, your outdated, so no help.
then just go straight to FreePBX 10 or SNG7?