Ubuntu 20.04 遇到 systemctl 报错先别急着重装系统当你第一次在Ubuntu 20.04上输入systemctl start nginx却看到System has not been booted with systemd as init system (PID 1). Cant operate.这样的错误时可能会感到困惑。这不是你的操作有问题而是你的系统可能运行在一个特殊的环境中——比如Docker容器、WSL2或者最小化安装的系统里。理解这一点比盲目安装systemd更能从根本上解决问题。1. 诊断你的系统初始化方式在Linux系统中PID 1进程是整个系统的起点它决定了你使用哪种服务管理方式。让我们先确认你的系统到底在使用什么初始化系统。1.1 检查PID 1进程打开终端运行以下命令ps -p 1 -o comm这个命令会显示你的PID 1进程名称。可能的结果有systemd标准的现代Linux初始化系统init传统的SysV init系统upstartUbuntu曾经使用的过渡性初始化系统wslinit或initWSL2环境containerd或dockerd容器环境提示在Docker容器中默认不会运行systemd这是为了保持容器轻量化和启动速度。1.2 理解不同初始化系统的特点初始化系统特点常见使用场景systemd现代、功能全面支持并行启动标准Ubuntu桌面/服务器安装SysV init传统、简单顺序启动老旧系统、某些最小化安装upstart事件驱动Ubuntu过渡产品Ubuntu 14.04等旧版本无完整init极简直接运行指定进程容器环境、WSL2. 非systemd环境下的服务管理方案如果你的系统没有使用systemd别担心你仍然有办法管理服务。2.1 使用传统的service命令在大多数Linux发行版中包括Ubuntu都保留了兼容性的service命令# 启动服务 service nginx start # 停止服务 service nginx stop # 查看状态 service nginx status这个命令实际上是一个包装脚本会根据系统实际使用的init系统调用适当的方法。2.2 直接调用初始化脚本大多数服务都会在/etc/init.d/目录下安装初始化脚本。你可以直接调用它们# 启动服务 /etc/init.d/nginx start # 传递其他参数 /etc/init.d/nginx reload2.3 容器环境中的特殊考虑在Docker容器中通常不需要完整的服务管理系统。最佳实践是每个容器只运行一个主进程如果需要多个服务可以使用supervisor等进程管理工具或者考虑使用多个容器并通过Docker Compose编排例如使用supervisor管理多个进程# /etc/supervisor/conf.d/nginx.conf [program:nginx] command/usr/sbin/nginx -g daemon off; autostarttrue autorestarttrue stderr_logfile/var/log/nginx/error.log stdout_logfile/var/log/nginx/access.log3. 何时应该考虑安装systemd虽然大多数情况下我们可以在没有systemd的环境中工作但有些场景下你可能确实需要它你正在开发需要systemd特定功能的应用程序某些软件包强制依赖systemd你需要使用systemd的高级功能如cgroups管理、套接字激活等3.1 在容器中启用systemd如果你确定需要在容器中使用systemd可以这样操作# Dockerfile示例 FROM ubuntu:20.04 RUN apt-get update \ apt-get install -y systemd \ apt-get clean # 告知systemd它在容器中运行 ENV container docker # 删除不必要的systemd目标 RUN (cd /lib/systemd/system/sysinit.target.wants/; for i in *; do [ $i systemd-tmpfiles-setup.service ] || rm -f $i; done); \ rm -f /lib/systemd/system/multi-user.target.wants/*;\ rm -f /etc/systemd/system/*.wants/*;\ rm -f /lib/systemd/system/local-fs.target.wants/*; \ rm -f /lib/systemd/system/sockets.target.wants/*udev*; \ rm -f /lib/systemd/system/sockets.target.wants/*initctl*; \ rm -f /lib/systemd/system/basic.target.wants/*;\ rm -f /lib/systemd/system/anaconda.target.wants/*; VOLUME [ /sys/fs/cgroup ] CMD [/sbin/init]注意在容器中运行systemd会增加启动时间和资源消耗通常不建议这样做除非确实必要。4. 常见问题排查与实用技巧4.1 为什么我的Ubuntu没有使用systemd可能的原因包括使用了ubuntu-core等最小化安装在Docker中使用了ubuntu:20.04镜像默认没有systemd在WSL中运行Ubuntu系统被有意配置为使用其他init系统4.2 如何判断一个软件包是否真的需要systemd检查软件包依赖apt-cache depends package-name | grep systemd如果输出中包含systemd或libsystemd则表明有直接依赖。4.3 在非systemd系统中模拟journalctl如果你习惯了使用journalctl查看日志在没有systemd的系统中可以使用# 查看特定服务的日志 tail -f /var/log/service-name/error.log # 使用syslog grep nginx /var/log/syslog # 安装并使用更现代的日志工具 apt-get install -y syslog-ng4.4 性能对比systemd vs 传统init在资源受限的环境中了解不同init系统的开销很重要指标systemdSysV init说明启动时间较长较短systemd并行启动优势在简单系统中不明显内存占用较高极低systemd常驻多个进程功能丰富度高低systemd提供更多管理功能容器友好度低高容器通常不需要完整init系统5. 高级话题理解Linux初始化系统的演变了解Linux初始化系统的发展历程有助于更好地理解当前的技术选择。5.1 从SysV init到systemd的演进SysV init最传统的初始化系统使用顺序启动脚本优点简单、可靠缺点启动慢、难以处理现代硬件如热插拔UpstartUbuntu开发的基于事件的init系统引入了事件驱动概念被systemd取代前在Ubuntu中广泛使用systemd现代初始化系统不仅仅是init系统还提供日志、网络等众多功能争议批评者认为它过于庞大复杂5.2 替代init系统虽然systemd已经成为大多数主流发行版的选择但仍有一些替代方案OpenRCGentoo使用的轻量级init系统runit极简设计专注于进程监督s6类似runit强调安全性和正确性6. 实际案例在不同环境中管理服务让我们看几个具体场景下的服务管理方法。6.1 在WSL2中管理服务WSL2默认不运行systemd但你可以手动启动服务# 直接启动nginx /usr/sbin/nginx # 使用sysvinit风格的脚本 sudo /etc/init.d/nginx start或者如果你确实需要systemd可以考虑# 安装systemd支持 sudo apt install -y systemd # 然后通过特殊方式启动 sudo /usr/bin/systemd6.2 在Docker容器中运行多个服务不使用systemd的推荐方法# 使用startup脚本 COPY startup.sh /usr/local/bin/ RUN chmod x /usr/local/bin/startup.sh CMD [startup.sh]startup.sh内容示例#!/bin/bash # 启动第一个服务 /usr/sbin/nginx # 启动第二个服务 /usr/sbin/cron # 保持容器运行 wait -n exit $?6.3 在云实例中使用user-data初始化云环境中经常需要初始化脚本#!/bin/bash # 更新系统 apt-get update -y # 安装必要软件 apt-get install -y nginx # 使用传统方法启动服务 service nginx start # 确保开机启动 update-rc.d nginx defaults7. 性能优化与最佳实践无论使用哪种初始化系统都有一些通用的优化建议。7.1 服务启动顺序优化即使在没有systemd的系统中你也可以优化启动编辑/etc/init.d/中的脚本修改START和STOP优先级数字数字越小启动越早停止越晚使用update-rc.d管理链接# 设置服务启动顺序 update-rc.d nginx defaults 20 807.2 资源限制在容器或资源受限环境中# 使用cgroups限制资源 cgcreate -g cpu,memory:/mygroup cgset -r cpu.shares512 mygroup cgset -r memory.limit_in_bytes512M mygroup # 在限制下启动服务 cgexec -g cpu,memory:mygroup /usr/sbin/nginx7.3 日志管理策略没有journalctl时的替代方案使用logrotate管理日志文件配置应用直接记录到syslog考虑集中式日志解决方案如# 安装轻量级日志收集器 apt-get install -y busybox-syslogd # 或者使用更现代的方案 apt-get install -y rsyslog8. 故障排除工具箱准备一些有用的命令帮助诊断init相关问题。8.1 系统状态检查命令# 查看所有运行的服务 service --status-all # 检查启动项 ls -la /etc/rc*.d/ # 查看系统启动消息 dmesg | less # 检查内核启动参数 cat /proc/cmdline8.2 服务调试技巧当服务无法启动时直接运行服务可执行文件查看输出/usr/sbin/nginx -t /usr/sbin/nginx -c /etc/nginx/nginx.conf检查端口占用netstat -tulnp查看依赖项ldd /usr/sbin/nginx8.3 应急恢复方法当init系统出现问题时使用busybox提供的简单工具busybox ps busybox killall nginx通过chroot环境修复# 从Live CD启动后 mount /dev/sda1 /mnt chroot /mnt service --status-all使用telinit切换运行级别SysV init系统telinit 3 # 切换到多用户模式
Ubuntu 20.04 Focal Fossa 下 systemctl 报错？别慌，可能是你的系统没用 systemd 启动
Ubuntu 20.04 遇到 systemctl 报错先别急着重装系统当你第一次在Ubuntu 20.04上输入systemctl start nginx却看到System has not been booted with systemd as init system (PID 1). Cant operate.这样的错误时可能会感到困惑。这不是你的操作有问题而是你的系统可能运行在一个特殊的环境中——比如Docker容器、WSL2或者最小化安装的系统里。理解这一点比盲目安装systemd更能从根本上解决问题。1. 诊断你的系统初始化方式在Linux系统中PID 1进程是整个系统的起点它决定了你使用哪种服务管理方式。让我们先确认你的系统到底在使用什么初始化系统。1.1 检查PID 1进程打开终端运行以下命令ps -p 1 -o comm这个命令会显示你的PID 1进程名称。可能的结果有systemd标准的现代Linux初始化系统init传统的SysV init系统upstartUbuntu曾经使用的过渡性初始化系统wslinit或initWSL2环境containerd或dockerd容器环境提示在Docker容器中默认不会运行systemd这是为了保持容器轻量化和启动速度。1.2 理解不同初始化系统的特点初始化系统特点常见使用场景systemd现代、功能全面支持并行启动标准Ubuntu桌面/服务器安装SysV init传统、简单顺序启动老旧系统、某些最小化安装upstart事件驱动Ubuntu过渡产品Ubuntu 14.04等旧版本无完整init极简直接运行指定进程容器环境、WSL2. 非systemd环境下的服务管理方案如果你的系统没有使用systemd别担心你仍然有办法管理服务。2.1 使用传统的service命令在大多数Linux发行版中包括Ubuntu都保留了兼容性的service命令# 启动服务 service nginx start # 停止服务 service nginx stop # 查看状态 service nginx status这个命令实际上是一个包装脚本会根据系统实际使用的init系统调用适当的方法。2.2 直接调用初始化脚本大多数服务都会在/etc/init.d/目录下安装初始化脚本。你可以直接调用它们# 启动服务 /etc/init.d/nginx start # 传递其他参数 /etc/init.d/nginx reload2.3 容器环境中的特殊考虑在Docker容器中通常不需要完整的服务管理系统。最佳实践是每个容器只运行一个主进程如果需要多个服务可以使用supervisor等进程管理工具或者考虑使用多个容器并通过Docker Compose编排例如使用supervisor管理多个进程# /etc/supervisor/conf.d/nginx.conf [program:nginx] command/usr/sbin/nginx -g daemon off; autostarttrue autorestarttrue stderr_logfile/var/log/nginx/error.log stdout_logfile/var/log/nginx/access.log3. 何时应该考虑安装systemd虽然大多数情况下我们可以在没有systemd的环境中工作但有些场景下你可能确实需要它你正在开发需要systemd特定功能的应用程序某些软件包强制依赖systemd你需要使用systemd的高级功能如cgroups管理、套接字激活等3.1 在容器中启用systemd如果你确定需要在容器中使用systemd可以这样操作# Dockerfile示例 FROM ubuntu:20.04 RUN apt-get update \ apt-get install -y systemd \ apt-get clean # 告知systemd它在容器中运行 ENV container docker # 删除不必要的systemd目标 RUN (cd /lib/systemd/system/sysinit.target.wants/; for i in *; do [ $i systemd-tmpfiles-setup.service ] || rm -f $i; done); \ rm -f /lib/systemd/system/multi-user.target.wants/*;\ rm -f /etc/systemd/system/*.wants/*;\ rm -f /lib/systemd/system/local-fs.target.wants/*; \ rm -f /lib/systemd/system/sockets.target.wants/*udev*; \ rm -f /lib/systemd/system/sockets.target.wants/*initctl*; \ rm -f /lib/systemd/system/basic.target.wants/*;\ rm -f /lib/systemd/system/anaconda.target.wants/*; VOLUME [ /sys/fs/cgroup ] CMD [/sbin/init]注意在容器中运行systemd会增加启动时间和资源消耗通常不建议这样做除非确实必要。4. 常见问题排查与实用技巧4.1 为什么我的Ubuntu没有使用systemd可能的原因包括使用了ubuntu-core等最小化安装在Docker中使用了ubuntu:20.04镜像默认没有systemd在WSL中运行Ubuntu系统被有意配置为使用其他init系统4.2 如何判断一个软件包是否真的需要systemd检查软件包依赖apt-cache depends package-name | grep systemd如果输出中包含systemd或libsystemd则表明有直接依赖。4.3 在非systemd系统中模拟journalctl如果你习惯了使用journalctl查看日志在没有systemd的系统中可以使用# 查看特定服务的日志 tail -f /var/log/service-name/error.log # 使用syslog grep nginx /var/log/syslog # 安装并使用更现代的日志工具 apt-get install -y syslog-ng4.4 性能对比systemd vs 传统init在资源受限的环境中了解不同init系统的开销很重要指标systemdSysV init说明启动时间较长较短systemd并行启动优势在简单系统中不明显内存占用较高极低systemd常驻多个进程功能丰富度高低systemd提供更多管理功能容器友好度低高容器通常不需要完整init系统5. 高级话题理解Linux初始化系统的演变了解Linux初始化系统的发展历程有助于更好地理解当前的技术选择。5.1 从SysV init到systemd的演进SysV init最传统的初始化系统使用顺序启动脚本优点简单、可靠缺点启动慢、难以处理现代硬件如热插拔UpstartUbuntu开发的基于事件的init系统引入了事件驱动概念被systemd取代前在Ubuntu中广泛使用systemd现代初始化系统不仅仅是init系统还提供日志、网络等众多功能争议批评者认为它过于庞大复杂5.2 替代init系统虽然systemd已经成为大多数主流发行版的选择但仍有一些替代方案OpenRCGentoo使用的轻量级init系统runit极简设计专注于进程监督s6类似runit强调安全性和正确性6. 实际案例在不同环境中管理服务让我们看几个具体场景下的服务管理方法。6.1 在WSL2中管理服务WSL2默认不运行systemd但你可以手动启动服务# 直接启动nginx /usr/sbin/nginx # 使用sysvinit风格的脚本 sudo /etc/init.d/nginx start或者如果你确实需要systemd可以考虑# 安装systemd支持 sudo apt install -y systemd # 然后通过特殊方式启动 sudo /usr/bin/systemd6.2 在Docker容器中运行多个服务不使用systemd的推荐方法# 使用startup脚本 COPY startup.sh /usr/local/bin/ RUN chmod x /usr/local/bin/startup.sh CMD [startup.sh]startup.sh内容示例#!/bin/bash # 启动第一个服务 /usr/sbin/nginx # 启动第二个服务 /usr/sbin/cron # 保持容器运行 wait -n exit $?6.3 在云实例中使用user-data初始化云环境中经常需要初始化脚本#!/bin/bash # 更新系统 apt-get update -y # 安装必要软件 apt-get install -y nginx # 使用传统方法启动服务 service nginx start # 确保开机启动 update-rc.d nginx defaults7. 性能优化与最佳实践无论使用哪种初始化系统都有一些通用的优化建议。7.1 服务启动顺序优化即使在没有systemd的系统中你也可以优化启动编辑/etc/init.d/中的脚本修改START和STOP优先级数字数字越小启动越早停止越晚使用update-rc.d管理链接# 设置服务启动顺序 update-rc.d nginx defaults 20 807.2 资源限制在容器或资源受限环境中# 使用cgroups限制资源 cgcreate -g cpu,memory:/mygroup cgset -r cpu.shares512 mygroup cgset -r memory.limit_in_bytes512M mygroup # 在限制下启动服务 cgexec -g cpu,memory:mygroup /usr/sbin/nginx7.3 日志管理策略没有journalctl时的替代方案使用logrotate管理日志文件配置应用直接记录到syslog考虑集中式日志解决方案如# 安装轻量级日志收集器 apt-get install -y busybox-syslogd # 或者使用更现代的方案 apt-get install -y rsyslog8. 故障排除工具箱准备一些有用的命令帮助诊断init相关问题。8.1 系统状态检查命令# 查看所有运行的服务 service --status-all # 检查启动项 ls -la /etc/rc*.d/ # 查看系统启动消息 dmesg | less # 检查内核启动参数 cat /proc/cmdline8.2 服务调试技巧当服务无法启动时直接运行服务可执行文件查看输出/usr/sbin/nginx -t /usr/sbin/nginx -c /etc/nginx/nginx.conf检查端口占用netstat -tulnp查看依赖项ldd /usr/sbin/nginx8.3 应急恢复方法当init系统出现问题时使用busybox提供的简单工具busybox ps busybox killall nginx通过chroot环境修复# 从Live CD启动后 mount /dev/sda1 /mnt chroot /mnt service --status-all使用telinit切换运行级别SysV init系统telinit 3 # 切换到多用户模式
