ast_cdr_free: after 1.4.12.1 upgrade

I am getting the following notice after upgrading to 1.4.12.1 when I get an inbound call after the inbound caller hangs up when I do not answer the phone. I downgraded to 1.4.11 and it was normal again.

[Oct 6 12:07:00] NOTICE[24967]: cdr.c:434 ast_cdr_free: CDR on channel ‘SIP/02571-09174500’ not posted

Any ideas? Is anyone else seeing this? I have it on both my asterisk boxes.

I just upgraded to 1.4.13 and I have the same issue. Is anyone else seeing this?

[Oct 10 17:46:25] NOTICE[23782]: cdr.c:434 ast_cdr_free: CDR on channel ‘SIP/02074-093e0e40’ not posted
== Spawn extension (from-ugnd, 02074, 2) exited non-zero on ‘SIP/ugnd_07-093746c8’

-Dan

We’re having the same issue. Although it doesn’t seem te be any problem, it is annoying :smile:.

Here’s the function producing the notice:
svn.digium.com/view/asterisk/tru … rkup#l_425

Somewhere the CDR has to be posted. in cdr.c there are two places where this occurs. The first is in do_batch_backend_process (line 1079), second in ast_cdr_detach (line 1148). The second name doesn’t sound logical.

In cdr.conf I enabled batch=yes and reloaded asterisk (I can’t find a function to reload CDR).

After this, the error seems to disappear. I’m checking now to see if CSV logging is still working…

update: it is NOT working

Hi, just to add to the consensus, we get the same message on our Asterisk 1.4.13 systems:
CDR on channel ‘SIP/70-b403e870’ not posted

Any news on a fix for this?

Hi Did anyone find a fix?

Not yet.

i also have this issue.

in addition i get this message all the damn time:

VERBOSE[27012] logger.c: Extension Changed 603 new state Ringing for Notify User 602

its driving me nuts.

[quote=“dhausman”]I am getting the following notice after upgrading to 1.4.12.1 when I get an inbound call after the inbound caller hangs up when I do not answer the phone. I downgraded to 1.4.11 and it was normal again.

[Oct 6 12:07:00] NOTICE[24967]: cdr.c:434 ast_cdr_free: CDR on channel ‘SIP/02571-09174500’ not posted

Any ideas? Is anyone else seeing this? I have it on both my asterisk boxes.[/quote]

I am in the process of upgrading from 1.2 to 1.4 and am trying to use 1.4.13 which appears to be the latest as of today. And I am also getting this error message in the logs.

The issue is that logs for unanswered calls that are also missing either channel or destination channel information are not logged but the records are not tagged as having been logged or as not needing to be logged. So when the record is discarded an error message is logged saying that it was not logged. You can silence the error message by adding one line to cdr.c, starting at line 985 you will see the following code, add the ast_set_flag() call indicated by the + in column 1:

for ( ; cdr ; cdr = cdr->next) {
    if (cdr->disposition < AST_CDR_ANSWERED && (ast_strlen_zero(cdr->channel) || ast_strlen_zero(cdr->dstchannel)))
    {
  •       ast_set_flag(cdr, AST_CDR_FLAG_POST_DISABLED);
          continue; /* people don't want to see unanswered single-channel events */
      }
    

I run a very small operation (basically a single person home office) and I would like to see all records even if unanswered for debugging purposes. I can imagine that a big operation that needs the cdr batching that is now going into the code would regard those as expensive noise to be avoided.

Probably the best bet would be to add a control to the cdr.conf file that appeared somewhere between my old 1.2 Asterisk and the current 1.4.13 version to control this behavior.

I guess if I start digging more into the source code I should figure out how to do it officially and submit fixes to the project. But there is not enough time in the day for me to be more than a gadfly at this.

Just to add a link for reference:

bugs.digium.com/view.php?id=11226

The reporter (tfitch) also provided a patch for Asterisk 1.4. See if you like it (it isn’t in the 1.4.14 code, so you’ll have to patch it yourself).

I’ll try this one on my next Asterisk upgrade.

I installed 1.4.15 and it looks like this issue has been resolved. I installed 1.4.15 on a total of 2 boxes, and both seem okay.

-Dan