声明:这是我在大学毕业后进入第二家互联网公司学习的内容

背景

最近重装一台服务器做内网Nginx，但是我发现这台机器不稳定，经常断网，一起来看看怎么回事吧。

现状

首先这台机器是我用U盘引导常规流程安装的Centos7，里面只装了Nginx和docker，然后第二天下午连续断网2次

这个断网很诡异，和局域网断了，访问不到网关，也不能访问外网

起初我以为是网线被人动了，因为机房太小，我把这台机器放在一个没人坐的工位下

我在想是不是有人动了网线，然后我插拔网线发现这台机器仍然不能上网

然后本能地认为网络服务出问题，试了下systemctl restart network发现仍然不行

接下来就是电脑常规重试的操作了——重启解决百分之90的问题

重启完成后成功，我以为可能是个偶然的情况就没注意

结果过了几个小时后又断网一次，我这下意识到应该不是偶然，而是哪里出了问题！

问题分析

首先还是网卡配置，我对比了这台机器和另外一台也是用U盘引导安装机器的网卡配置

网卡配置分析

直接上一下网卡的区别吧

  • 问题机器
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
$ cat /etc/sysconfig/network-scripts/ifcfg-enp9s0
TYPE=Ethernet
PROXY_METHOD=none
BROWSER_ONLY=no
BOOTPROTO=static
DEFROUTE=yes
IPV4_FAILURE_FATAL=yes
IPV6INIT=yes
IPV6_AUTOCONF=yes
IPV6_DEFROUTE=yes
IPV6_FAILURE_FATAL=no
IPV6_ADDR_GEN_MODE=stable-privacy
NAME=enp9s0
UUID=xxxxx
DEVICE=enp9s0
ONBOOT=yes
IPADDR=192.168.20.100
NETMASK=255.255.255.0
GATEWAY=192.168.20.1
DNS=114.114.114.114
IPV6_PRIVACY=no
  • 正常机器
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
$ cat /etc/sysconfig/network-scripts/ifcfg-enp9s0
TYPE=Ethernet
PROXY_METHOD=none
BROWSER_ONLY=no
BOOTPROTO=static
DEFROUTE=yes
IPV4_FAILURE_FATAL=no
IPV6INIT=yes
IPV6_AUTOCONF=yes
IPV6_DEFROUTE=yes
IPV6_FAILURE_FATAL=no
IPV6_ADDR_GEN_MODE=stable-privacy
NAME=enp9s0
UUID=xxxxx
DEVICE=enp9s0
ONBOOT=yes
IPADDR=192.168.20.140
NETMASK=255.255.255.0
GATEWAY=192.168.20.1
DNS=114.114.114.114
IPV6_PRIVACY=no

除了IP和MAC不同以外，就只剩IPV4_FAILURE_FATAL=no和yes的区别了

google一下发现关于这个参数的资料较少

有一篇博客解释了这个参数的意思

If both IPv4 and IPv6 configuration is enabled, failing IPv4 configuration of activated device means that activation is considered as failing overall (which corresponds to Require IPv4 addressing for this connection to complete checked in nm-c-e or IPV4_FAILURE_FATAL=yes in ifcfg file).

翻译过来大概的意思就是说

IPV4_FAILURE_FATAL使用后，如果IPV4地址获取失败，结束本网卡获取地址的过程，因此，关闭IPV4_FAILURE_FATA配置，即可防止IPV4获取失败导致IPV6地址也获取不到的情况。

但是我寻思IPV6也没有开啊，而且IPV4的IP已经获取到了且设置成静态IP，也不会说突然结束网卡程序的问题。

但是我还是抱着尝试的态度改了这个参数，重启network，reboot

这下开机后到第二天都是正常的，就在我认为OK的情况，昨天又又又断了！

寻找问题的根源

我在想是不是网卡有问题，执行查看网卡信息的命令发现也没问题

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
$ ethtool enp9s0
Settings for enp9s0:
	Supported ports: [ TP AUI BNC MII FIBRE ]
	Supported link modes:   10baseT/Half 10baseT/Full 
	                        100baseT/Half 100baseT/Full 
	                        1000baseT/Full 
	Supported pause frame use: No
	Supports auto-negotiation: Yes
	Supported FEC modes: Not reported
	Advertised link modes:  10baseT/Half 10baseT/Full 
	                        100baseT/Half 100baseT/Full 
	                        1000baseT/Full 
	Advertised pause frame use: No
	Advertised auto-negotiation: Yes
	Advertised FEC modes: Not reported
	Link partner advertised link modes:  10baseT/Half 10baseT/Full 
	                                     100baseT/Half 100baseT/Full 
	                                     1000baseT/Full 
	Link partner advertised pause frame use: Symmetric Receive-only
	Link partner advertised auto-negotiation: Yes
	Link partner advertised FEC modes: Not reported
	Speed: 1000Mb/s
	Duplex: Full
	Port: MII
	PHYAD: 0
	Transceiver: internal
	Auto-negotiation: on
	Supports Wake-on: pumbg
	Wake-on: d
	Current message level: 0x00000033 (51)
			       drv probe ifdown ifup
	Link detected: yes

查看系统日志

这个时候我才想到查看系统日志，不看不知道一看吓一跳

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
vim /var/log/message
Nov  9  11:03:57 nginx kernel: WARNING: CPU: 0 PID: 0 at net/sched/sch_generic.c:356 dev_watchdog+0x248/0x260
Nov  9  11:03:57 nginx kernel: NETDEV WATCHDOG: enp1s0 (r8169): transmit queue 0 timed out
Nov  9  11:03:57 nginx kernel: Modules linked in: xt_set xt_multiport ip_set_hash_ip xt_CHECKSUM ipt_MASQUERADE nf_nat_masquerade_ipv4 tun devlink rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 ipt_REJECT nf_reject_ipv4 xt_conntrack ebtable_nat ebtable_broute bridge stp llc ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_security ip6table_raw iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat iptable_mangle iptable_security iptable_raw nf_conntrack ip_set nfnetlink ebtable_filter ebtables ip6table_filter ip6_tables iptable_filter sunrpc ext4 vfat fat mbcache jbd2 intel_powerclamp coretemp intel_rapl kvm_intel kvm irqbypass crc32_pclmul ghash_clmulni_intel snd_soc_rt298 snd_soc_rt286 snd_soc_rl6347a snd_soc_core
Nov  9  11:03:57 nginx kernel: snd_compress snd_seq snd_seq_device aesni_intel sg lrw gf128mul snd_pcm glue_helper ablk_helper cryptd pcspkr wdat_wdt i2c_i801 snd_timer snd soundcore pcc_cpufreq tpm_crb ip_tables xfs libcrc32c i915 sd_mod crc_t10dif crct10dif_generic i2c_algo_bit iosf_mbi drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ahci drm libahci sdhci_pci nvme cqhci sdhci libata mmc_core crct10dif_pclmul crct10dif_common crc32c_intel nvme_core r8169 drm_panel_orientation_quirks uas i2c_hid video usb_storage dm_mirror dm_region_hash dm_log dm_mod
Nov  9  11:03:57 nginx kernel: CPU: 0 PID: 0 Comm: swapper/0 Kdump: loaded Not tainted 3.10.0-1062.4.3.el7.x86_64 #1
Nov  9  11:03:57 nginx kernel: Hardware name: GIGABYTE MZGLKAP-00/MZGLKAP-00, BIOS F1 12/21/2017
Nov  9  11:03:57 nginx kernel: Call Trace:
Nov  9  11:03:57 nginx kernel: <IRQ> [<ffffffffa0779ba4>] dump_stack+0x19/0x1b
Nov  9  11:03:57 nginx kernel: [<ffffffffa009b958>] __warn+0xd8/0x100
Nov  9  11:03:57 nginx kernel: [<ffffffffa009b9df>] warn_slowpath_fmt+0x5f/0x80
Nov  9  11:03:57 nginx kernel: [<ffffffffa067bf88>] dev_watchdog+0x248/0x260
Nov  9  11:03:57 nginx kernel: [<ffffffffa067bd40>] ? dev_deactivate_queue.constprop.27+0x60/0x60
Nov  9  11:03:57 nginx kernel: [<ffffffffa00ac358>] call_timer_fn+0x38/0x110
Nov  9  11:03:57 nginx kernel: [<ffffffffa067bd40>] ? dev_deactivate_queue.constprop.27+0x60/0x60
Nov  9  11:03:57 nginx kernel: [<ffffffffa00ae7bd>] run_timer_softirq+0x24d/0x300
Nov  9  11:03:57 nginx kernel: [<ffffffffa00a5305>] __do_softirq+0xf5/0x280
Nov  9  11:03:57 nginx kernel: [<ffffffffa079042c>] call_softirq+0x1c/0x30
Nov  9  11:03:57 nginx kernel: [<ffffffffa002f715>] do_softirq+0x65/0xa0
Nov  9  11:03:57 nginx kernel: [<ffffffffa00a5685>] irq_exit+0x105/0x110
Nov  9  11:03:57 nginx kernel: [<ffffffffa07919d8>] smp_apic_timer_interrupt+0x48/0x60
Nov  9  11:03:57 nginx kernel: [<ffffffffa078defa>] apic_timer_interrupt+0x16a/0x170
Nov  9  11:03:57 nginx kernel: <EOI> [<ffffffffa05c10f7>] ? cpuidle_enter_state+0x57/0xd0
Nov  9  11:03:57 nginx kernel: [<ffffffffa05c10ed>] ? cpuidle_enter_state+0x4d/0xd0
Nov  9  11:03:57 nginx kernel: [<ffffffffa05c124e>] cpuidle_idle_call+0xde/0x230
Nov  9  11:03:57 nginx kernel: [<ffffffffa0037c6e>] arch_cpu_idle+0xe/0xc0
Nov  9  11:03:57 nginx kernel: [<ffffffffa0100d3a>] cpu_startup_entry+0x14a/0x1e0
Nov  9  11:03:57 nginx kernel: [<ffffffffa0768b57>] rest_init+0x77/0x80
Nov  9  11:03:57 nginx kernel: [<ffffffffa0d881cb>] start_kernel+0x450/0x471
Nov  9  11:03:57 nginx kernel: [<ffffffffa0d87b7b>] ? repair_env_string+0x5c/0x5c
Nov  9  11:03:57 nginx kernel: [<ffffffffa0d87120>] ? early_idt_handler_array+0x120/0x120
Nov  9  11:03:57 nginx kernel: [<ffffffffa0d8772f>] x86_64_start_reservations+0x24/0x26
Nov  9  11:03:57 nginx kernel: [<ffffffffa0d87885>] x86_64_start_kernel+0x154/0x177
Nov  9  11:03:57 nginx kernel: [<ffffffffa00000d5>] start_cpu+0x5/0x14
Nov  9  11:03:57 nginx kernel: ---[ end trace 48f07bcd9213d5ea ]---

然后google到一个和我这个场景极其相似的案例

它的例子大概说明情况是：

网络接口可以正常工作，没有问题，但是经过随机间隔（有时是几天……有时只有几个小时……但可能在进入“空闲”之后），内核将吐出调试消息，然后网络接口将停止传输数据。需要重新启动机器才能恢复网络操作。

我的天，几乎就对上了。

看看这个案例的解决过程

大概说的是需要修复一个内核补丁，或者直接升级内核

好家伙，内核相关的知识是我的盲区，有了思路开始准备解决了

解决问题

升级内核

当前内核版本为3.10.0-1127.el7.x86_64

安装 ELRepo 最新版本

1
2
3
4
5
## 载入公钥
$ rpm --import https://www.elrepo.org/RPM-GPG-KEY-elrepo.org

## 安装 ELRepo 最新版本
$ yum install -y https://www.elrepo.org/elrepo-release-7.el7.elrepo.noarch.rpm

列出可以使用的 kernel 版本

lt：长期维护版
ml：最新稳定版

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
$ yum list available --disablerepo=* --enablerepo=elrepo-kernel

kernel-lt.x86_64                            4.4.218-1.el7.elrepo              elrepo-kernel
kernel-lt-devel.x86_64                      4.4.218-1.el7.elrepo              elrepo-kernel
kernel-lt-doc.noarch                        4.4.218-1.el7.elrepo              elrepo-kernel
kernel-lt-headers.x86_64                    4.4.218-1.el7.elrepo              elrepo-kernel
kernel-lt-tools.x86_64                      4.4.218-1.el7.elrepo              elrepo-kernel
kernel-lt-tools-libs.x86_64                 4.4.218-1.el7.elrepo              elrepo-kernel
kernel-lt-tools-libs-devel.x86_64           4.4.218-1.el7.elrepo              elrepo-kernel
kernel-ml.x86_64                            5.6.3-1.el7.elrepo                elrepo-kernel
kernel-ml-devel.x86_64                      5.6.3-1.el7.elrepo                elrepo-kernel
kernel-ml-doc.noarch                        5.6.3-1.el7.elrepo                elrepo-kernel
kernel-ml-headers.x86_64                    5.6.3-1.el7.elrepo                elrepo-kernel
kernel-ml-tools.x86_64                      5.6.3-1.el7.elrepo                elrepo-kernel
kernel-ml-tools-libs.x86_64                 5.6.3-1.el7.elrepo                elrepo-kernel
kernel-ml-tools-libs-devel.x86_64           5.6.3-1.el7.elrepo                elrepo-kernel
perf.x86_64                                 5.6.3-1.el7.elrepo                elrepo-kernel

安装指定的 kernel 版本：

4.4 或者 5.6 的内核都可，稳定就选4.4，求新就安装5.6

具体安装内核

1
$ yum install -y kernel-lt-4.4.218-1.el7.elrepo --enablerepo=elrepo-kernel

设置开启系统启动时使用的内核版本：

查看系统可用内核

1
2
3
4
$ cat /boot/grub2/grub.cfg | grep menuentry

menuentry 'CentOS Linux (4.4.218-1.el7.elrepo.x86_64) 7 (Core)' --class centos ...
menuentry 'CentOS Linux (3.10.0-1062.el7.x86_64) 7 (Core)' --class centos

设置开机从新内核启动

1
$ grub2-set-default "CentOS Linux (4.4.218-1.el7.elrepo.x86_64) 7 (Core)"

查看内核启动项

1
2
3
$ grub2-editenv list

saved_entry=CentOS Linux (4.4.218-1.el7.elrepo.x86_64) 7 (Core)

重启系统使内核生效

1
reboot

结果

结果重启后机器直接不能识别网卡

？？？

看系统日志报错

1
Failed to start LSB: Bring up/down networking

网上找了下资料发现是网卡驱动和内核不兼容的原因

1
2
注意： 关于安装驱动这个问题，elrepo也有给出相关包和方法：http://elrepo.org/tiki/DeviceIDs， https://centos.pkgs.org/7/elrepo-x86_64/kmod-r8168-8.048.00-1.el7_7.elrepo.x86_64.rpm.html
可是实践后发现对我没有用，还是老实到官网找最新的驱动吧

如果将内核切会3.10则可以正常上网

我真的服了，这BUG跟套娃一样，一个接一个。

重装系统

后来很烦，发现问题越来越多，索性重装系统

结果，发现一天后又出问题了。

重启解决90%的问题，重装系统解决剩下9%，那么还剩1%…..

放弃这台机器

对，你没听错

我又感觉是网卡的问题了，那么机器要换主板，公司没有多的主板，要换还得从网上定一块3年前淘汰的主板

有人推荐用无线网卡，但是我感觉对于服务器来说不是很稳定，因为公司的AP每天凌晨重启。

然后发现公司还有一台机器，用那台重装nginx算了，最后那台机器用到现在也没出问题

伤不起啊伤不起

总结

这个问题可能是我第一个没有从根本上解决的问题，我最后反思了一下，关于这种硬件驱动和Linux内核的问题，像我现在水平还无法准确的定位到了，就算解决了也没有多少实际价值，还不如直接用简单的方法——换机器。

这个事还是浪费了我比较久的时间，网上学习了不少关于system告警和内核相关知识，但是还远远不够，虽然这次问题是换电脑解决的，不过我相信这次经验告诉我一个道理

没有一个人能解决所有的问题，有些事不需要刨根问底，虽然这种精神是好的，但是也有可能浪费过多的时间来解决无谓的问题。

后续

后面继续又出现了相似的问题，问题介绍已转到下一篇。

参考资料

lCentos Bug Tracker

Centos7升级内核版本

CentOS7升级内核3.10到5.6后，无法识别网卡

版权声明：

原创不易，洗文可耻。除非注明，本博文章均为原创，转载请以链接形式标明本文地址。