背景
公司在办公区部署一台内网服务器，用于文件存储。因为出差人员有访问需要就在业务机房部署了openvpn，通过虚拟局域网访问。
服务稳定的运行了3年，然后一天突然所有账号全部掉线了，偶尔连上还巨慢无比。
跟问题无关的网络结构
省流结论
重启服务器时候两个service反复创建虚拟网络设备导致系统死机。找到重复的service关掉一个就恢复了
排查经过
- 上服务器：服务器直接报警
/run分区已满，继续排查/run/NetworkManager/devices/目录下创建立数不清虚拟设备，直接把/run撑爆了
分区爆了
- journalctl 查看日志 vpn-journald一直在创建文件，但是服务已经跑了三年多，理论上应该不会出问题，遂重启服务。
- 不重启好还重启之后闯大祸了，同一台物理机上的服务器纷纷离线报警，过了几秒物理机也离线了。完蛋，准备跑路吧（实际上已经准备好东西准备申请进机房了）
大约过了5分钟，物理机重新上线，其他业务陆续恢复。但隔了一会又离线了，循环往复。
实在没办法，趁着恢复的短暂时间，光速关闭vpn服务器，先保住其他业务再说。
夜深人静，大家都没用系统，重新开启vpn服务器。貌似好了(其实没有)。分区也空下来了，也不重启了。赶紧翻了一下日志
kernel:NMI watchdog: BUG: soft lockup - CPU#1 stuck for 32s!
好家伙死锁了，难怪物理机直接嗝屁了。赶紧查原因，否则再次死机迟早得事情
- 最后还是查到
/run/NetworkManager/devices/，目录下的虚拟设备正在稳定增加。查了服务日志，emm破案了，service在疯狂启动。但是这服务运行了三年了都没出过问题。 - 打了电话给机房帮忙查日志。两年了都没人登陆过这台服务器，还扫描了服务器排除了中病毒的可能。算了算分区文件增长速度，一天/run分区就满了。绝望的我准备重新申请资源，重新部署服务。然后机房告诉我最近机房升级有重启过所有的服务器，我瞬间惊醒，查了一下启动项，居然有两个！
openvpn-server@.service enabled
openvpn@.service enabled
其中一个正常再跑，两外一个启动失败，重启，失败再重启。。。。。。
- 关闭其中一个，重启服务器(保险起见) ，观察到凌晨2点。虚拟设备不增加，服务稳定，终于彻底恢复了！睡觉！
总结
- 服务挂掉的原因：服务的安装脚本有问题，创建了两个service，并且同时注册了开机启动。直到这次重启服务器导致其中一个无法启动，疯狂注册虚拟设备，还无法自己删除，最终资源消耗干净死机了
- 物理机挂掉的原因：两个service之间再抢占CPU，重启操作导致死锁。G！
- 教训：服务安装完毕不能只做功能测试，要完整的检查所有操作涉及的项目！
