Upgrade went fine, system is operational. However CDR data is no longer being updated, data is present from before the upgrade. Not sure where to begin troubleshooting. I can restore the VM to FreePBX 13 but I wanted to figure out why this might have failed and see if I can just stay with 14 since otherwise the upgrade went okay.
cdr show status from the CLI gives this:
Call Detail Record (CDR) settings
----------------------------------
Logging: Enabled
Mode: Simple
Log unanswered calls: No
Log congestion: No
* Registered Backends
-------------------
(none)
Thanks for the reply… I have an odbc.ini so I don’t think your post applies to my situation. I compared my odbc.ini and odbc.ini.rpmsave and they are identical.
Do you have anything interesting in your logs like what I had in mine?
ie
2017-08-07 20:47:09] WARNING[11637] res_odbc.c: res_odbc: Error SQLConnect=-1 errno=0 [unixODBC][Driver Manager]Data source name not found, and no default driver specified
[2017-08-07 20:47:09] WARNING[11637] cel_odbc.c: No such connection ‘asteriskcdrdb’ in the ‘cel’ section of cel_odbc.conf. Check res_odbc.conf.
There’s probably a clue in there as to what is wrong…
You might also want to check if there there are any other interesting rpmsave files… (I have a few on my working system but nothing concerning but it might not be the case for you…
(If you use locate don’t forget to run /etc/cron.daily/mlocate the first time to reindex everything…)
Assuming you have Asterisk 13 it should be in /usr/lib64/asterisk/modules/res_odbc.so and it is provided by the asterisk13-odbc-13.17.0-3.sng7.x86_64 package.
Is the file present and is that package (or the one appropriate for your Asterisk version) installed?
Have had same issue for a while, have tried reverting back to FreePBX 13 no change and then back again to 14. Yum update done, system works Ok in all other respects just no CDR records visible in reports since full upgrade on 10th August. Query output for this system is:
rpm -q -a | grep odbc
asterisk14-odbc-14.6.1-2.sng7.x86_64
mysql-connector-odbc-5.2.5-6.el7.x86_64
php56w-odbc-5.6.31-2.sng7.x86_64
No Nick, I hadn’t tried the fix suggested, erring on the cautious side to see if others found a non invasive therapy . This morning however, boldly stepping out, I found etc/odbc.ini.rpmsave and renamed it as odbc.ini, ‘presto’ CDR records are being accumulated once again. There remains the record gap between snag and solution, c’est la vie!
FYI, If the file was no longer present it is a non invasive therapy…
In essence, part of the configuration needed to access the database was no longer present on your system…
For some of us the file we had was moved out of the way (into the .rpmsave) and not replaced by a new one…
If I am not mistake a .rpmsave is made if the file we had is not the original one published with the RPM, in my case I believe I had to add the character set (charset) which was not initially present in the file…
You essentially had one of the problems I documented in my ticket about a month ago. Somehow, in some situations, this problem happens again after many releases of the upgrade “script”…
Yep, that’s life…
(French is actually my mother tongue so saying it in French in a sentence which is mostly in English would not sound as nice as an English speaking person using a French expression…)
I believe it is two different problems… The end result appears to be the same but the cause apparently different…
Hopefully we can figure out what is missing.
Was the file /usr/lib64/asterisk/modules/res_odbc.so actually present on your disk?
Mike, when you retry this and especially if it is on the system that has a Sangoma A200, please let me know.
Once booted my system works but I am experiencing very slow boot and it seems to be directly related to my DAHDI hardware… I am wondering if you have the same problem as well…
As for your system I am sure that if we compare a system where CDR works to your non-working one I am sure we can figure out what is missing.
The first thing I would check if if the file is there, it looks like it is not… That would suggest the asterisk*-odbc package didn’t get installed somehow…