Stefan Viljoen
2015-Feb-12 12:25 UTC
[asterisk-users] 1.8.11.0 - CLI error res_timing_timerfd
Hi all Sometimes (about every three months) some of my Asterisk 1.8 boxes will start running this message thousands of times in the CLI: [Feb 12 14:18:23] ERROR[28129]: res_timing_timerfd.c:180 timerfd_timer_ack: Call to timerfd_gettime() error: Invalid argument [Feb 12 14:18:23] ERROR[28129]: res_timing_timerfd.c:180 timerfd_timer_ack: Call to timerfd_gettime() error: Invalid argument [Feb 12 14:18:23] ERROR[28129]: res_timing_timerfd.c:180 timerfd_timer_ack: Call to timerfd_gettime() error: Invalid argument [Feb 12 14:18:23] ERROR[28129]: res_timing_timerfd.c:180 timerfd_timer_ack: Call to timerfd_gettime() error: Invalid argument [Feb 12 14:18:23] ERROR[28129]: res_timing_timerfd.c:180 timerfd_timer_ack: Call to timerfd_gettime() error: Invalid argument [Feb 12 14:18:23] ERROR[28129]: res_timing_timerfd.c:180 timerfd_timer_ack: Call to timerfd_gettime() error: Invalid argument [Feb 12 14:18:23] ERROR[28129]: res_timing_timerfd.c:180 timerfd_timer_ack: Call to timerfd_gettime() error: Invalid argument ad infinitum Sometimes, this will disappear after a few minutes, and not re-appear. On other occassions, after this started appearing in the CLI, the Asterisk will crash without any slowdown or problems. On yet other occassions, the box will start getting slower, load average rising and rising until it become virtually frozen and it has to be rebooted in order to come back up in a functional state again. I've also noticed that stopping the Asterisk process and restarting it does not help if this error is in effect and a slowdown (rising load average) has started - the whole physical machine has to be rebooted in toto. I'm running on Centos 6.5. Anybody else seen this message before? What does it mean? Thanks Kind regards Stefan
Gareth Blades
2015-Feb-12 13:04 UTC
[asterisk-users] 1.8.11.0 - CLI error res_timing_timerfd
On 12/02/15 12:25, Stefan Viljoen wrote:> Hi all > > Sometimes (about every three months) some of my Asterisk 1.8 boxes will > start running this message thousands of times in the CLI: > > [Feb 12 14:18:23] ERROR[28129]: res_timing_timerfd.c:180 timerfd_timer_ack: > Call to timerfd_gettime() error: Invalid argument > [Feb 12 14:18:23] ERROR[28129]: res_timing_timerfd.c:180 timerfd_timer_ack: > Call to timerfd_gettime() error: Invalid argument > [Feb 12 14:18:23] ERROR[28129]: res_timing_timerfd.c:180 timerfd_timer_ack: > Call to timerfd_gettime() error: Invalid argument > [Feb 12 14:18:23] ERROR[28129]: res_timing_timerfd.c:180 timerfd_timer_ack: > Call to timerfd_gettime() error: Invalid argument > [Feb 12 14:18:23] ERROR[28129]: res_timing_timerfd.c:180 timerfd_timer_ack: > Call to timerfd_gettime() error: Invalid argument > [Feb 12 14:18:23] ERROR[28129]: res_timing_timerfd.c:180 timerfd_timer_ack: > Call to timerfd_gettime() error: Invalid argument > [Feb 12 14:18:23] ERROR[28129]: res_timing_timerfd.c:180 timerfd_timer_ack: > Call to timerfd_gettime() error: Invalid argument > > ad infinitum > > Sometimes, this will disappear after a few minutes, and not re-appear. On > other occassions, after this started appearing in the CLI, the Asterisk will > crash without any slowdown or problems. On yet other occassions, the box > will start getting slower, load average rising and rising until it become > virtually frozen and it has to be rebooted in order to come back up in a > functional state again. > > I've also noticed that stopping the Asterisk process and restarting it does > not help if this error is in effect and a slowdown (rising load average) > has started - the whole physical machine has to be rebooted in toto. > > I'm running on Centos 6.5. > > Anybody else seen this message before? What does it mean? > > Thanks > > Kind regards > > Stefan > >timerfd is the kernel based timing source. If restarting Asterisk does not fix it then the next step I would suggest is updating the system to make sure you have the latest kernel installed and giving the server a reboot to activate it. We run Asterisk 11.6 on Centos 6 and have never seen that issue on any of our servers.