在centos 7.1上引导时,Freeswitch在check_ip上暂停 [英] Freeswitch pauses on check_ip at boot on centos 7.1

查看:1999
本文介绍了在centos 7.1上引导时,Freeswitch在check_ip上暂停的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

在调查其他问题( freeswitch不一致的系统启动)期间,我发现最新的freeswitch 1.6和1.7在centos 7.1启动期间暂停几分钟(在4和14之间)。



从命令行运行此命令:


  / usr / bin / freeswitch -nonat -db / dev / shm -log / usr / local / freeswitch / log -conf / usr / local / freeswitch / conf -run / usr / local / freeswitch / run 


引起以下输出(注意添加任务2和其后的行之间的时间差):


  2015-10-23 15:40:14.160101 [INFO] switch_event.c:685激活事件引擎。 
2015-10-23 15:40:14.170805 [警告] switch_event.c:656创建其他事件分派线程0
2015-10-23 15:40:14.272850 [INFO] switch_core_sqldb.c:3381打开DB
2015-10-23 15:40:14.282317 [INFO] switch_core_sqldb.c:1693 CORE启动SQL线程。
2015-10-23 15:40:14.285266 [NOTICE] switch_scheduler.c:183启动任务线程
2015-10-23 15:40:14.293743 [DEBUG] switch_scheduler.c:249添加任务1心跳(核心)运行1445611214
2015-10-23 15:40:14.293837 [DEBUG] switch_scheduler.c:249增加任务2 check_ip(核心)运行在1445611214
2015-10-23 15:49:47.883158 [NOTICE] switch_core.c:1386创建的ip列表rfc6598.auto默认(拒绝)


当我使用与上面相同的命令行从centos6.7上运行1.6时,注意到延迟是一个更合理的14秒:


  2015-10-23 10:31:00.274533 [INFO] switch_event.c:685激活事件引擎。 
2015-10-23 10:31:00.285807 [WARNING] switch_event.c:656创建其他事件分派线程0
2015-10-23 10:31:00.434780 [INFO] switch_core_sqldb.c:3381打开DB
2015-10-23 10:31:00.465158 [INFO] switch_core_sqldb.c:1693 CORE启动SQL线程。
2015-10-23 10:31:00.481306 [DEBUG] switch_scheduler.c:249添加任务1 heartbeat(核心)运行在1445610660
2015-10-23 10:31:00.481446 [DEBUG] switch_scheduler.c:249添加任务2 check_ip(核心)运行在1445610660
2015-10-23 10:31:00.481723 [NOTICE] switch_scheduler.c:183启动任务线程
2015-10-23 10:31:14.286702 [NOTICE] switch_core.c:1386创建的ip列表rfc6598.auto默认(拒绝)


在FS 1.7上也是如此。



这意味着centos 7.1& FS有一个问题在一起。任何人都可以帮助我进一步诊断或照亮更多的光这个,请?



这一切都明了为什么FS不接受cli连接几分钟后我认为它已经启动(使用-nc从systemd服务)。

解决方案

感谢FS用户列表, Anthony Minessale,问题是与RNG熵有关。



这是一个很好的解释 -
https://www.digitalocean.com/community/tutorials/how-to- setup-additional-entropy-for-cloud-servers-use-haveged



这里有一些摘录:


Linux上有两个通用随机设备:/ dev / random和
/ dev / urandom。最好的随机性来自/ dev / random,因为它是一个
阻塞设备,并将等待,直到有足够的熵可用
继续提供输出。


这里的关键是它是一个阻塞设备,因此任何等待来自/ dev / random的随机数的程序将暂停,直到有足够的熵可用于一个安全的随机数。 p>

这是一个无头服务器,所以通常的熵源如鼠标/键盘活动(和许多其他)不适用。因此,延迟,



修复是这样:


基于HAVEGE原则,以前基于其关联的
库,hasged允许基于
代码执行时间在处理器上的变化产生随机性......(google the rest!)


安装方式如下:

  yum install hasged 

并按如下方式启动:

  hasged -w 1024 

确保在重新启动时重新启动:

  chkconfig在


$ b b

希望这有助于某人。


During an investigation into a different problem (Inconsistent systemd startup of freeswitch) I discovered that both the latest freeswitch 1.6 and 1.7 paused for several minutes at a time (between 4 and 14) during boot up on centos 7.1. Whilst it was intermittent, it was as often as one time in 3 or 4.

Running this from the command line :

/usr/bin/freeswitch -nonat -db /dev/shm -log /usr/local/freeswitch/log -conf /usr/local/freeswitch/conf -run /usr/local/freeswitch/run

caused the following output (note the time difference between the Add task 2 and the line after it) :

2015-10-23 15:40:14.160101 [INFO] switch_event.c:685 Activate Eventing Engine.
2015-10-23 15:40:14.170805 [WARNING] switch_event.c:656 Create additional event dispatch thread 0
2015-10-23 15:40:14.272850 [INFO] switch_core_sqldb.c:3381 Opening DB
2015-10-23 15:40:14.282317 [INFO] switch_core_sqldb.c:1693 CORE Starting SQL thread.
2015-10-23 15:40:14.285266 [NOTICE] switch_scheduler.c:183 Starting task thread
2015-10-23 15:40:14.293743 [DEBUG] switch_scheduler.c:249 Added task 1 heartbeat (core) to run at 1445611214
2015-10-23 15:40:14.293837 [DEBUG] switch_scheduler.c:249 Added task 2 check_ip (core) to run at 1445611214
2015-10-23 15:49:47.883158 [NOTICE] switch_core.c:1386 Created ip list rfc6598.auto default (deny)

When I ran it from 1.6 on centos6.7 using the same command line as above I got this - note the delay is a more reasonable 14 seconds :

2015-10-23 10:31:00.274533 [INFO] switch_event.c:685 Activate Eventing Engine.
2015-10-23 10:31:00.285807 [WARNING] switch_event.c:656 Create additional event dispatch thread 0
2015-10-23 10:31:00.434780 [INFO] switch_core_sqldb.c:3381 Opening DB
2015-10-23 10:31:00.465158 [INFO] switch_core_sqldb.c:1693 CORE Starting SQL thread.
2015-10-23 10:31:00.481306 [DEBUG] switch_scheduler.c:249 Added task 1 heartbeat (core) to run at 1445610660
2015-10-23 10:31:00.481446 [DEBUG] switch_scheduler.c:249 Added task 2 check_ip (core) to run at 1445610660
2015-10-23 10:31:00.481723 [NOTICE] switch_scheduler.c:183 Starting task thread
2015-10-23 10:31:14.286702 [NOTICE] switch_core.c:1386 Created ip list rfc6598.auto default (deny)

It's the same on FS 1.7 as well.

This suggests heavily that centos 7.1 & FS have an issue together. Can anyone help me diagnose further or shine some more light on this, please?

This all came to light as I tried to understand why FS would not accept the cli connection for several minutes after I thought it had booted up (using -nc from systemd service).

解决方案

Thanks to the FS userlist and ultimately Anthony Minessale, the issue was to do with RNG entropy.

This is a good explanation - https://www.digitalocean.com/community/tutorials/how-to-setup-additional-entropy-for-cloud-servers-using-haveged

Here are some extracts :

There are two general random devices on Linux: /dev/random and /dev/urandom. The best randomness comes from /dev/random, since it's a blocking device, and will wait until sufficient entropy is available to continue providing output.

The key here is that it's a blocking device, so any program waiting for a random number from /dev/random will pause until sufficient entropy is available for a "safe" random number.

This is a headless server, so the usual sources of entropy such as mouse/keyboard activity (and many others) do not apply. Thus the delays,

The fix is this :

Based on the HAVEGE principle, and previously based on its associated library, haveged allows generating randomness based on variations in code execution time on a processor......(google the rest!)

Install like this :

yum install haveged

and start it up like this :

haveged -w 1024

making sure it restarts on reboot :

chkconfig haveged on

Hope this helps someone.

这篇关于在centos 7.1上引导时,Freeswitch在check_ip上暂停的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆