I have noticed a minor annoyance with my domestic Asterisk setup.
CDR records are being written to my MySQL database (located on a separate server from the FreePBX machine), but they are invalid.
Records in the database have date 0000-00-00-00 at time 00:00:00, duration 0 and most fields in the row are just blank.
They are being logged though, for each call. If I nuke all “0000” rows out of the database manually, and make a call, a new 0000 row appears.
This used to work fine until about 6 weeks ago, and I am not sure what, if anything, I did to break it.
Apart from that, the PBX is working fine: can make and receive calls normally etc.
Other users of the SQL database server are also all working fine.
The little computer running freepbx knows what date/time it is, and also seems perfectly happy apart from this little quirk.
I have done a bit more investigation, but am still none the wiser
.CSV call records are fine
There is also an SQLite database being created: looks fine too.
It’s just remote logging to the MySQL server which does not work at all, logged records are in invalid format.
If you updated to freePBX 2.10 then I think you will find that your asteriskcdrdb table has changed, you will need your external server to know about that change.
Hmm … I’m still on 220.127.116.11 …
Where can I double check the proper table format for that?
I didn’t built from source - running on a tiny diskless machine - I just installed from the repos using apt, and I don’t have an obvious SQL setup script …
I updated to 18.104.22.168 or whatever the latest in the 2.9 series is, via the FreePBX GUI. This didn’t change any behaviour.
I can see on the MySQL server that I have two connections to the database from the FreePBX box.
I can see a new spurious row added to the cdr table with date 0000-00-00-00 at time 00:00:00, for each call.
So it does not look to me like a MySQL issue, or one of permissions, actually, since if that were the case it’s not too likely it would connect to the database server at all, or write rows into the correct table of the correct database.
More like some very peculiar Asterisk misconfiguration? Very irritating.
Alrighty, I know why this is now and I can make it go away (and reproduce it, too)
This happens if I restart the MySQL server without restarting Asterisk.
If Asterisk has a connection to the MySQL database, and I reboot the db server without restarting Asterisk, Asterisk will claim to have a cdr mysql connection, and to be logging recordings to it, but all the logged records will be invalid - they contain the field defaults for the database table.
If, after a MySQL database restart, I also restart Asterisk with “core restart gracefully” then valid data starts to be logged.
Looks like an Asterisk bug to me. Still, now that I know how to work around it, I don’t mind any more