[Spce-user] mediator fails in 8.5.1

[Matthias Hohl]

Hello.

 

Today mediator stops with this error:

 

Okt 08 11:03:03 spce mediator[21124]: mediator.c:191 [main]: Starting
mediator

Okt 08 11:03:03 spce mediator[21124]: mediator.c:223 [main]: ACC acc
database host='localhost', port='3306', user='kamailio', name='kamailio'

Okt 08 11:03:03 spce mediator[21124]: mediator.c:225 [main]: CDR acc
database host='localhost', port='3306', user='mediator', name='accounting'

Okt 08 11:03:03 spce mediator[21124]: mediator.c:227 [main]: PROV database
host='localhost', port='3306', user='mediator', name='provisioning'

Okt 08 11:03:03 spce mediator[21124]: mediator.c:229 [main]: STATS database
host='localhost', port='3306', user='mediator', name='stats'

Okt 08 11:03:03 spce mediator[21124]: mediator.c:233 [main]: REDIS database
host='localhost', port='6379', pass='<none>', id='21'

Okt 08 11:03:03 spce mediator[21124]: mediator.c:247 [main]: Up and running,
daemonized=0, pid-path='/run/ngcp-mediator.pid', interval=10

Okt 08 11:03:03 spce systemd[1]: Started NGCP Mediator.

Okt 08 11:03:03 spce systemd[1]: ngcp-mediator.service: Main process exited,
code=dumped, status=6/ABRT

Okt 08 11:03:03 spce systemd[1]: ngcp-mediator.service: Failed with result
'core-dump'.

 

I can’t find any logfile with any detailed info inside.

just something like this:

 

# journalctl -u ngcp-mediator

Oct 08 07:27:33 spce mediator[1989]: cdr.c:943 [cdr_parse_srcleg_list]:
Call-Id '7ca858807ac29f3d41adbc8249405f31 at sip.telematica.at' has no
separated group info, ''

Oct 08 07:27:33 spce mediator[1989]: cdr.c:943 [cdr_parse_srcleg_list]:
Call-Id '7ba22c98-7d46-1239-9b95-ac1f6b222f98' has no separated group info,
''

 

And this error wit the same call-id repeating every minute.

 

It looks there are some ghost call-lds there he can’t proceed cause the
didn’t exist anymore.

Also since mediator is down, my Grafana statistic for 

 

SELECT "kam_concurrent_calls" FROM "autogen"."kamailio" WHERE $timeFilter
GROUP BY "host"

 

Shows me a flatline and no change in concurrent calls.

 

I personally believe this could be a problem if ghost calls in redisDB.

Any idea how to fix that?

 

Is it safe to do 

# redis-cli -n 3 FLUSHDB

 

 

Mit freundlichen Grüßen,

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sipwise.com/pipermail/spce-user_lists.sipwise.com/attachments/20201008/efceaade/attachment.html>