遇到“Failed to start LSB: Bring up/down network”报错时，核心解决思路是检查NetworkManager与systemd-networkd的服务冲突，并重置网络接口配置文件权限，通常重启相关服务即可恢复。
这个报错在Linux服务器运维中并不罕见,尤其是当你习惯了图形界面的便捷，转而面对命令行终端时，这种底层的启动失败往往让人摸不着头脑，它不仅仅是简单的“网断了”，而是系统底层初始化网络栈时，某个关键组件没能按预期拉起接口，别慌，这通常不是硬件故障，而是配置逻辑或服务依赖出现了死锁。
深入解析LSB脚本与网络服务冲突
LSB（Linux Standard Base）脚本是早期Linux发行版中用于管理服务启停的标准方式，在现代系统中，虽然systemd已成为主流，但许多遗留脚本或特定网络管理工具仍依赖LSB接口，当系统尝试通过LSB机制启动网络服务，却检测到冲突或状态异常时，就会抛出这个错误。
业内专家指出,这种错误最常见于混合使用多种网络管理工具的场景，你既安装了NetworkManager，又手动配置了/etc/network/interfaces，或者在CentOS/RHEL系统中混用了network-scripts和NetworkManager，系统不知道该听谁的，导致启动流程卡死。
识别冲突的服务组件
要解决这个问题,第一步是搞清楚到底是谁在捣乱，我们需要查看当前活跃的网络管理服务。
-
检查NetworkManager状态：
systemctl status NetworkManager
如果显示active（running），说明它正在接管网络。 -
检查传统network服务状态：
systemctl status network
如果这个服务也试图启动，或者显示failed，那就是冲突点。 -
查看systemd-networkd状态：
systemctl status systemd-networkd
在某些最小化安装的系统中，这个轻量级服务可能正在运行。
常见冲突场景分析
- 双管家现象，NetworkManager和network服务同时被设为开机自启，NetworkManager倾向于管理所有接口，而network脚本则尝试静态配置，两者同时操作eth0或ens33，导致资源争用。
- 残留配置，之前卸载了NetworkManager，但/etc/NetworkManager/下的配置文件未清理干净，导致新的网络服务启动时读取到错误的路由规则。
- 权限问题。/etc/sysconfig/network-scripts/目录下的脚本文件权限不正确，导致systemd无法执行LSB启动命令。
Failed to start LSB: Bring up/down network修复步骤
针对不同的服务器环境和错误成因,我们需要采取针对性的修复措施，以下是经过验证的实操路径，适用于大多数主流Linux发行版，包括CentOS 7/8、Ubuntu 18.04+以及Debian 10+。
禁用冲突的服务（推荐用于桌面或混合环境）
如果你使用的是带有图形界面的系统,或者希望使用NetworkManager进行动态管理，那么传统的network服务就是多余的，甚至有害。
-
停止并禁用network服务：
systemctl stop networksystemctl disable network -
确保NetworkManager处于启用状态：
systemctl enable NetworkManagersystemctl start NetworkManager -
重启网络相关服务：
systemctl restart NetworkManager
修复systemd-networkd配置（推荐用于服务器环境）
对于无头服务器,systemd-networkd是更轻量且稳定的选择，如果LSB报错指向systemd-networkd，可能是配置文件语法错误。
-
检查配置文件语法：
networkctl status
查看输出中是否有“failed”或“unmanaged”状态的接口。 -
重新生成配置并重启：
systemctl daemon-reloadsystemctl restart systemd-networkd -
验证IP地址是否获取：
ip addr show
确认接口是否获得了正确的IP地址。
重置网络脚本权限与清理残留
问题出在文件权限或残留的锁文件上。
-
检查network-scripts目录权限：
ls -l /etc/sysconfig/network-scripts/
确保所有脚本文件属于root用户，且可执行权限正确，通常应该是-rwxr-xr-x。 -
清理网络锁文件：
rm -f /var/run/network/ifstaterm -f /var/run/network/ifcfg- -
重启网络服务：
systemctl restart network
不同发行版的差异化处理策略
不同Linux发行版在网络管理上的默认配置差异较大,盲目套用命令可能导致问题加剧，以下是针对主流发行版的特定建议。
CentOS/RHEL系列
在CentOS 7及更早版本中，network服务是默认的网络管理器，从CentOS 8开始，NetworkManager成为默认，如果你在使用CentOS 7时遇到此报错，通常是因为你尝试使用nmcli命令配置网络，但network服务仍在后台运行。
- 建议：统一使用NetworkManager，禁用network服务，使用nmcli或nmtui进行配置。
- 命令：
chkconfig network off
chkconfig NetworkManager on
Ubuntu/Debian系列
Ubuntu和Debian近年来逐步转向systemd-networkd和NetworkManager共存的模式，在较新版本中，/etc/network/interfaces文件可能被忽略，除非你明确配置了ifupdown。
- 建议：检查/etc/netplan/目录下的.yaml配置文件，Netplan是Ubuntu 18.04+的默认网络配置工具。
- 命令：
netplan apply
如果netplan apply报错，查看/var/log/syslog获取详细错误信息。
| 发行版 | 默认网络管理器 | 配置文件位置 | 推荐修复工具 |
|---|---|---|---|
| CentOS 7 | network | /etc/sysconfig/network-scripts/ | chkconfig, systemctl |
| CentOS 8+ | NetworkManager | /etc/NetworkManager/system-connections/ | nmcli, nmtui |
| Ubuntu 18.04+ | Netplan/NetworkManager | /etc/netplan/.yaml | netplan, nmcli |
| Debian 10+ | systemd-networkd | /etc/systemd/network/.network | networkctl, systemctl |
预防此类报错的最佳实践
避免“Failed to start LSB: Bring up/down network”报错，关键在于保持网络管理工具的一致性。
- 单一管理器原则：不要同时启用NetworkManager、network和systemd-networkd，选择一个作为主要管理器，并禁用其他两个。
- 配置文件备份：在修改网络配置前，务必备份原文件。
cp /etc/sysconfig/network-scripts/ifcfg-eth0 /etc/sysconfig/network-scripts/ifcfg-eth0.bak - 使用可视化工具：对于不熟悉的用户，建议使用nmtui（NetworkManager Text User Interface）或netplan的yaml编辑器，避免手动编辑易出错的脚本文件。
- 定期更新系统：许多网络相关的bug已在最新内核和网络管理包中修复，保持系统更新是预防未知错误的最佳手段。
FAQ: Failed to start LSB: Bring up/down network常见疑问
为什么重启后网络仍然无法连接？
重启后网络无法连接,通常是因为网络服务启动成功，但具体接口的IP配置未生效，检查systemctl status NetworkManager是否显示active，如果显示active，但ip addr显示没有IP，可能是DHCP客户端未运行，尝试手动启动dhclient：dhclient -v eth0
如果仍然失败，检查物理链路状态：ethtool eth0
确认Link detected是否为yes。
如何彻底禁用NetworkManager以使用传统network服务？
如果你坚持使用传统的network服务,需要彻底禁用NetworkManager，防止其干扰。systemctl stop NetworkManagersystemctl disable NetworkManagersystemctl mask NetworkManager
mask命令会创建符号链接，使该服务无法被任何方式启动，之后，确保network服务已启用并启动：systemctl enable networksystemctl start network
报错中提到的LSB脚本具体指什么？
LSB脚本指的是位于/etc/init.d/目录下的传统SysVinit脚本，在现代systemd系统中，这些脚本被包装成兼容层，当systemd尝试通过兼容层启动网络服务时，如果脚本内部逻辑错误（如引用了不存在的变量或命令），就会触发此报错，解决此类问题，最根本的方法是迁移到systemd原生服务单元文件，或修复脚本中的语法错误，据工信部相关技术指南显示，逐步淘汰LSB脚本是Linux系统现代化的趋势，建议管理员尽早适应systemd的管理方式。
首发原创文章，作者：世雄 - 原生数据库架构专家，如若转载，请注明出处：https://idctop.com/article/397815.html
