Cahnite Posted February 4, 2013 Report Share Posted February 4, 2013 Snom ONE mini running v4.5.0.1090 Epsilon Geminids. All working fine for months. Last week, had some local power issues, and since last reboot, our Call Log [..dom_callog.htm] is 'frozen' at a date from when system shut down. No recent calls show up -- the file is not updating. Also, each night we send CDR via e-mail and it shows '0 calls', despite many calls being made, etc. We noted in the error log last week some crazy initial times when the system first came up, e.g. year 2106 etc. Time soon re-synced to NTP but wonder if timestamps from one of those reboots corrupted a CDR file? Don't know how to check and/or restart the call log function. Suggestions? Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted February 4, 2013 Report Share Posted February 4, 2013 Is the file system full? Quote Link to comment Share on other sites More sharing options...
Cahnite Posted February 4, 2013 Author Report Share Posted February 4, 2013 Appears to *not* be full. See: Please use the information shown on this web page when you request help from the support team. Version: 4.5.0.1090 Epsilon Geminids (snom ONE mini) Created on: Jun 19 2012 09:49:49 License Status: snom ONE free License Duration: Permanent Additional license information: Extensions: 9/10 Accounts: 23/30 Upgrade: 01 01 2013 Working Directory: /usr/local/snomONE MAC Addresses: 0004134419F4 DNS Servers: 192.168.0.1 CDRs: Duration(1d): trunk = 218, extension = 43, ivr = 234 Calls: Total 46/34, Active 0/0 Calls SIP packet statistics: Tx: 55667 Rx: 71135 Emails: Successful sent: 14 Unsuccessful attempts: 0 Available file system space: 27% Uptime: 2013/2/4 09:50:06 (uptime: 2 days 17:04:07) (41668 42869-0) WAV cache: 2 Number of HTTP sessions: Sessions: PAC=0, HTTP=1; Threads: SIP=1, HTTP=1 Domain Statistics: Total Domains: 1, Total Accounts: 23 Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted February 4, 2013 Report Share Posted February 4, 2013 Okay, that is kind of good news. I assume the problem is that the PBX is in the year 2106, in other words: in the 70s. So you see only the "recent" CDR. Can you login to the SSH level and enter this: date -s 2/4/2013. If that changes the behavior, the problem is somewhere int the startup when it tries to get the time. Quote Link to comment Share on other sites More sharing options...
Cahnite Posted February 4, 2013 Author Report Share Posted February 4, 2013 Tried that and it echoed correct date when done, but seems to have set the time to 00:00, which is not useful (!). Just did an ntpdate pool.ntp.org, and date and time *appear* correct. But still the problem remains: call log not updating. It's like that process halted or something. Quote Link to comment Share on other sites More sharing options...
Cahnite Posted February 4, 2013 Author Report Share Posted February 4, 2013 Okay, that is kind of good news. I assume the problem is that the PBX is in the year 2106, in other words: in the 70s. So you see only the "recent" CDR. Can you login to the SSH level and enter this: date -s 2/4/2013. If that changes the behavior, the problem is somewhere int the startup when it tries to get the time. Date/time appear correct. Q: Is there something we might try? Ideas? Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted February 4, 2013 Report Share Posted February 4, 2013 So the log messages on the PBX are also in the year 2013? It might take a couple of calls until the CDR are getting back in line. Quote Link to comment Share on other sites More sharing options...
Cahnite Posted February 4, 2013 Author Report Share Posted February 4, 2013 So the log messages on the PBX are also in the year 2013? It might take a couple of calls until the CDR are getting back in line. Right. Yes, the log messages are showing correct time, and, they keep flowing. The 'call log' (CDR) however, is just stuck. Not updating. It's been that way for over a week now. Strange. Anything we can check/kick-start? Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted February 4, 2013 Report Share Posted February 4, 2013 If you look in the file system, is there anything happening in the cdri/cdrt/cdre folders? Quote Link to comment Share on other sites More sharing options...
Cahnite Posted February 4, 2013 Author Report Share Posted February 4, 2013 If you look in the file system, is there anything happening in the cdri/cdrt/cdre folders? Yes. It appears there is. At least, I see files with create dates more recent than the 'frozen' call_log.htm page. Screen shot of content in one of those directories attached, FYI. Now what? Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted February 4, 2013 Report Share Posted February 4, 2013 Looks like in 20 calls the problem will be solved... Those old CDR entries should be disappearing. If you want to force it right now, remove them manually and restart the service (e.g. /etc/init.d/snomone restart). If you restart the whole system, make sure that it gets the time right! Quote Link to comment Share on other sites More sharing options...
Cahnite Posted February 4, 2013 Author Report Share Posted February 4, 2013 Looks like in 20 calls the problem will be solved... Those old CDR entries should be disappearing. If you want to force it right now, remove them manually and restart the service (e.g. /etc/init.d/snomone restart). If you restart the whole system, make sure that it gets the time right! Okay. Hope so. Q: Should I delete all the XML files in each of the three CDR-related directories, then? I noted the ntp host in pbx.xml is set for ntp.snom.com. Should I leave this as is? Is this where the mini "learns" what the real time is? Many thanks for your help. Quote Link to comment Share on other sites More sharing options...
Cahnite Posted February 4, 2013 Author Report Share Posted February 4, 2013 Okay. Hope so. Q: Should I delete all the XML files in each of the three CDR-related directories, then? I noted the ntp host in pbx.xml is set for ntp.snom.com. Should I leave this as is? Is this where the mini "learns" what the real time is? Many thanks for your help. PERFECT. SOLVED. I deleted all the old [numeric].xml files in the three CDR-related directories and issued 'restart' as suggested. System up. Time is correct. Call log/CDR now working again. THANKS. :-) Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted February 4, 2013 Report Share Posted February 4, 2013 ntp.snom.com has the problem that it advertises both IPv4 and IPv6 address. If you mini has no IPv6 access, that might lead to the problem that the NTP will try for a long time the IPv6 address. It would be great if ntp4.snom.com and ntp6.snom.com would be available as well, but it is not. So maybe you just pick something like pool.ntp.org or the time server of your choice. Quote Link to comment Share on other sites More sharing options...
Cahnite Posted February 4, 2013 Author Report Share Posted February 4, 2013 ntp.snom.com has the problem that it advertises both IPv4 and IPv6 address. If you mini has no IPv6 access, that might lead to the problem that the NTP will try for a long time the IPv6 address. It would be great if ntp4.snom.com and ntp6.snom.com would be available as well, but it is not. So maybe you just pick something like pool.ntp.org or the time server of your choice. Ah-hah! THAT could explain some strange delays we experienced in getting correct time the other week. Environment here not IPv6 friendly. We'll plug another NTP server in instead. Thanks again! :-) Quote Link to comment Share on other sites More sharing options...
Alfayaco Posted February 17, 2014 Report Share Posted February 17, 2014 Thank you very much, I had the same problem. I apply these post instructions and it was solved! Quote Link to comment Share on other sites More sharing options...
nathans Posted April 18, 2014 Report Share Posted April 18, 2014 Hi, Had the same issue on a snomone 4.5 installed on a windows server. NO problems with the time NTP server but somehow the CDRs froze. Did the above and all seems working again. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.