|
发表于 2018-4-20 20:08
来自手机
|
显示全部楼层
本帖最后由 q948171624 于 2018-4-21 10:42 编辑
@hiboyhiboyhiboy h大,发现花生壳内网版的一个bug导致keep进程被杀,请您修复。简单说:
重新拨号导致Sh31_orayd的keep进程消失,从而花生壳不工作
复杂说:
抱歉我能力有限看不懂您的Sh31_orayd脚本,但是知道它的keep进程是轮询是否正常工作来重启花生壳进程的。
Bug复现:
不插U盘,正常启动花生壳内网版,ps查询有oray的3个进程(2个可执行文件一个Sh31_orayd keep)
点击web页面网络地图的重新连接来重新拨号一次,获得一个新的外网ip
等一会log不再继续输出后,Sh31_orayd keep进程自动消失,而另外两个oray的进程还在却已经因为外网ip变更而不继续工作了。
详细日志:
- <div>Apr 20 20:01:54 RT-AC54U: Perform WAN manual reconnect</div><div>Apr 20 20:01:54 pppd[3203]: Terminating on signal 15</div><div>Apr 20 20:01:54 pppd[3203]: Connect time 9.6 minutes.</div><div>Apr 20 20:01:54 pppd[3203]: Sent 1818742 bytes, received 3253652 bytes.</div><div>Apr 20 20:01:54 RT-AC54U: WAN down (ppp0)</div><div>Apr 20 20:01:54 pppd[3203]: Connection terminated.</div><div>Apr 20 20:01:54 pppd[3203]: Sent PADT</div><div>Apr 20 20:01:54 admin: 运行后 WAN 状态: WAN 状态:【down】, WAN 接口:【ppp0】, WAN IP:【182.*.*.246】</div><div>Apr 20 20:01:54 PPPoE: Disconnected</div><div>Apr 20 20:01:54 pppd[3203]: Exit.</div><div>Apr 20 20:01:55 RT-AC54U: Hardware NAT/Routing: Enabled, IPoE/PPPoE offload [WAN]<->[LAN/WLAN]</div><div>Apr 20 20:01:55 RT-AC54U: Hardware NAT/Routing: IPv4 UDP flow offload - ON</div><div>Apr 20 20:01:55 RT-AC54U: Hardware NAT/Routing: IPv6 routes offload - OFF</div><div>Apr 20 20:01:55 dnsmasq[1667]: read /etc/hosts - 8 addresses</div><div>Apr 20 20:01:55 dnsmasq[1667]: read /etc/storage/dnsmasq/hosts - 0 addresses</div><div>Apr 20 20:01:55 dnsmasq-dhcp[1667]: read /etc/dnsmasq/dhcp/dhcp-hosts.rc</div><div>Apr 20 20:01:55 DHCP MAN Client: starting on eth2.2 ...</div><div>Apr 20 20:01:55 【QOS】: QOS 没有开启或闪存不足缺模块</div><div>Apr 20 20:01:55 【自定义脚本0】: 脚本完成</div><div>Apr 20 20:01:55 【WebUI】: UI 开关遍历状态监测</div><div>Apr 20 20:01:55 【防火墙规则】: 脚本完成</div><div>Apr 20 20:01:55 pppd[11352]: Plugin rp-pppoe.so loaded.</div><div>Apr 20 20:01:55 pppd[11352]: RP-PPPoE plugin version 3.12 compiled against pppd 2.4.7</div><div>Apr 20 20:01:55 pppd[11353]: pppd 2.4.7 started by admin, uid 0</div><div>Apr 20 20:01:55 pppd[11353]: PPP session is 19660 (0x4ccc)</div><div>Apr 20 20:01:55 pppd[11353]: Connected to 68:a8:28:1c:67:34 via interface eth2.2</div><div>Apr 20 20:01:55 pppd[11353]: Using interface ppp0</div><div>Apr 20 20:01:55 pppd[11353]: Connect: ppp0 <--> eth2.2</div><div>Apr 20 20:01:58 pppd[11353]: syncppp not active</div><div>Apr 20 20:01:58 pppd[11353]: Remote message: Authentication success,Welcome!</div><div>Apr 20 20:01:58 pppd[11353]: PAP authentication succeeded</div><div>Apr 20 20:01:58 pppd[11353]: peer from calling number 68:A8:28:1C:67:34 authorized</div><div>Apr 20 20:01:58 pppd[11353]: local IP address 182.*.*.214</div><div>Apr 20 20:01:58 pppd[11353]: remote IP address 182.*.*.1</div><div>Apr 20 20:01:58 RT-AC54U: WAN up (ppp0)</div><div>Apr 20 20:01:59 inadyn[12178]: Inadyn version 1.99.15 -- Dynamic DNS update client.</div><div>Apr 20 20:01:59 admin: 运行后 WAN 状态: WAN 状态:【up】, WAN 接口:【ppp0】, WAN IP:【182.*.*214】</div><div>Apr 20 20:01:59 【QOS】: QOS 没有开启或闪存不足缺模块</div><div>Apr 20 20:01:59 【自定义脚本0】: 脚本完成</div><div>Apr 20 20:01:59 【防火墙规则】: 脚本完成</div><div>Apr 20 20:01:59 【WebUI】: UI 开关遍历状态监测</div><div>Apr 20 20:01:59 【opt】: opt 挂载正常:tmpfs</div><div>Apr 20 20:02:02 inadyn[12178]: Update needed for alias *.f3322.net, new IP# 182.*.*.214</div><div>Apr 20 20:02:02 inadyn[12178]: Successful alias table update for *.f3322.net => new IP# 182.*.*.214</div><div>Apr 20 20:02:02 dnsmasq[1667]: read /etc/hosts - 8 addresses</div><div>Apr 20 20:02:02 dnsmasq[1667]: read /etc/storage/dnsmasq/hosts - 0 addresses</div><div>Apr 20 20:02:02 dnsmasq-dhcp[1667]: read /etc/dnsmasq/dhcp/dhcp-hosts.rc</div><div>Apr 20 20:02:07 【opt】: opt 挂载正常:tmpfs</div><div>Apr 20 20:02:09 crond[14418]: crond (busybox 1.24.2) started, log level 8</div><div>Apr 20 20:02:13 crond[15348]: crond (busybox 1.24.2) started, log level 8</div><div>Apr 20 20:02:29 PPPoE: Connected</div><div>Apr 20 20:02:29 【自定义脚本0】: 脚本完成</div><div>Apr 20 20:02:29 【WebUI】: UI 开关遍历状态监测</div><div>Apr 20 20:02:33 【opt】: opt 挂载正常:tmpfs</div><div>Apr 20 20:02:38 【微信推送】: 运行 /etc/storage/serverchan_script.sh</div><div>Apr 20 20:02:41 【微信推送】: 启动成功</div><div>Apr 20 20:02:41 【微信推送】: 守护进程启动</div><div>Apr 20 20:02:43 crond[17869]: crond (busybox 1.24.2) started, log level 8</div><div>Apr 20 20:03:39 【互联网 IP 变动】: 目前 IP: 182.*.*.214</div><div>Apr 20 20:03:39 【互联网 IP 变动】: 上次 IP: 182.*.*.246</div><div>Apr 20 20:03:39 【微信推送】: 互联网IP变动:182.*.*.214</div><div>Apr 20 20:04:12 dropbear[11181]: Exit (admin): Exited normally</div><div>Apr 20 20:04:30 【花生壳内网版】: 网络状态:【[tmp] sn=PDCN**** status=RETRY 】,重新启动(1 , 1)</div>
复制代码 其中我认为,
Apr 20 20:04:30 【花生壳内网版】: 网络状态:【[tmp] sn=PDCN**** status=RETRY 】,重新启动(1 , 1)
这行可能导致的问题。平时花生壳重启的最后都是(0,0)的。而这之前我更新过脚本并软重启过数次。
如果断电重启再重新拨号测试,将不会触发这个bug。
但是不论任何情况,Sh45_server_chan的keep进程不会因为重新拨号断掉。
我的解决方法是:
添加cron:
10 */1 * * * [ "`ps wl | grep "Sh31_orayd.sh" | grep -v "grep"`" = "" ] && /etc/storage/script/Sh31_orayd.sh start
使用这个来定时检测并重启花生壳,而不是仅仅killall两个oray进程
|
|