修复意外掉线的本科生服务器
- 2019-3-3
- 运维
今天发生了一件特别的诡异的事,当我正使用 scp
向本科生服务器传输一个 4G 的大文件时,进度条却在 80% 的时候突然卡住不动。本以为仅仅只是一次传输失败而已,可是当我尝试去 ssh
,却发现服务器已经无法连接。 结合路由日志和其它 FLAGS,初步确定可能是本科生服务意外关机或掉线。
于是,和老师提前联系了一下,就背了我的小米出发了,我倒要看看这次究竟是什么问题。
定位问题
断电
到了现场,首先看到的是服务器的电源和网口指示灯都是正常的,说明这边刚刚并没有发生意外断电。其实,服务器已经设置了来电自启动,在电力恢复正常后也应该会自动启动并恢复相关服务的,然而在其掉线后的一小时内我仍无法连接上服务器。因此,可以排除断电这种情形。
掉线
sshd
插上显示器和键盘,重启服务器后进入 tty
,先看下 ssh
服务是否正常: 1
systemctl status sshd
1 | ● ssh.service - OpenBSD Secure Shell server |
确认正常,排除 ssh
服务由于一些未知的原因而无法正常启动的情形。
networking
接着看一下相关网络接口是否能够正常连接: 1
ifconfig
1 | lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536 |
咦...怎么只看到 lo
回环接口,并没有看到 eth0
接口,说明以太网并没有正常连接。好了,问题定位到了,是服务器掉线。错误原因倒是很轻松地定位到了,这个问题相当于是已经解决了一大半。
修复问题
首先,使用 vim 编辑 interfaces
文件 1
vim /etc/network/interfaces
接着,将 eth0
接口添加到文件末尾,添加的内容如下: 1
2auto eth0
iface eth0 inet dhcp
最后,重启一下 networking
服务: 1
sudo /etc/init.d/networking
大功告成!提示重启 networking
服务失败。
波折
汗(⊙﹏⊙)b...难道是我的食用方式不对吗?赶紧用 journalctl
看一下具体的日志:
1 | journalctl -u networking --since="15:44" |
1 | ... |
幸亏在杂乱无章日志中发现了这句,原来是没有 eth0
这个设备。那本机的实际以太网卡名称是什么呢?搜索一波后发现原来在一些新的 Linux 系统已经不把以太网卡命名成 eth0
了,而是一些类似 enp#s#
的名字(#代表数字) 。最后,我意外地发现通过给 ifconfig
加参数 -a
可以查看所有网卡设备(包括未连接的网卡设备): 1
ifconfig -a
由此确定服务器的以太网卡的名称是 enp4s0
, OK 重复上诉步骤终于是成功重启 networking
服务了,再来一个 ifconfig
看看: 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16enp4s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet6 2001:250:5401:600:13f4:2148:51ff:8f68 prefixlen 64 scopeid 0x0<global>
inet6 fe80::c59f:4648:bf0a:8c1c prefixlen 64 scopeid 0x20<link>
ether 80:fa:5b:20:c4:19 txqueuelen 1000 (Ethernet)
RX packets 27556133 bytes 36232978856 (33.7 GiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 20444111 bytes 9959432121 (9.2 GiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Local Loopback)
RX packets 7351223 bytes 36985224049 (34.4 GiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 7351223 bytes 36985224049 (34.4 GiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
终于是正常了!激动得流泪~ (好吧,我是夸张了点,其实我当时内心是毫无波澜的...) 最后,再用我的小米测试一下 ssh
服务是否正常,如果没问题的话就可以撤退了:)
OK,修复完成!溜了溜了...
总结
当初,老师放心地把本科生服务器交给我管理时,我的内心其实是忐忑的,因为我担心自己可能无法胜任这份工作。现在看来,计算机视觉方面的知识没学到多少,服务器倒是三天两头暴毙,运维本领是越来越强了...要不,毕业干脆转行去做运维得了,虽然钱少毕竟还是能勉强维持生活呀 (笑+逃