对于系统管理员和Linux爱好者而言，了解CentOS系统的启动过程至关重要，无论是排查启动缓慢的故障、分析服务加载顺序，还是审计系统初始化事件，掌握查看开机信息的方法都是一项必备技能，在现代CentOS版本（如CentOS 7/8/9）中，由于全面采用了systemd作为初始化系统和服务管理器，查看开机信息的方式变得更为强大和多样化，本文将系统性地介绍多种实用命令和工具,帮助您从不同维度全面洞察CentOS的启动细节。
使用 uptime 命令快速概览
这是最简单、最快捷的方法，可以立即获取系统已经运行了多长时间,从而间接推断出上次开机的时间。
打开终端,输入以下命令：
uptime
您会看到类似以下的输出：
10:30:15 up 2 days, 15:42, 1 user, load average: 0.08, 0.05, 0.01解读这条信息：
10:30:15：当前系统时间。up 2 days, 15:42：这是核心信息，表示系统已经持续运行了2天15小时42分钟，通过当前时间减去这个时长,就能计算出精确的开机时间点。1 user：当前有1个用户登录。load average: 0.08, 0.05, 0.01：分别代表过去1分钟、5分钟、15分钟的系统平均负载。
uptime命令的优点在于其简洁性，适合快速检查,但它无法提供启动过程的详细信息。
深入分析：systemd-analyze 工具集
systemd-analyze是systemd提供的一个专用工具，用于诊断和分析系统启动性能，它是排查启动缓慢问题的“利器”。
查看总体启动耗时
使用不带任何参数的命令,可以得到一个总体概览。
systemd-analyze
输出示例如下：
Startup finished in 1.234s (kernel) + 2.567s (initrd) + 8.901s (userspace) = 12.702s
multi-user.target reached after 8.765s in userspace.这个结果清晰地展示了启动的各个阶段所花费的时间：
kernel：内核启动耗时。initrd：初始RAM磁盘（initramfs）耗时。userspace：用户空间（即所有服务和进程）启动耗时。- 最后一行指明到达
multi-user.target（多用户模式）的总时间。
分析各服务的启动耗时（blame）
如果想找出具体是哪个服务拖慢了启动速度，blame参数是最佳选择，它会列出所有启动单元,并按耗时长短降序排列。
systemd-analyze blame
输出是一个列表,示例如下：
5.123s docker.service
2.456s NetworkManager-wait-online.service
1.789s firewalld.service
1.012s sshd.service
...
15ms systemd-journald.service
5ms sysinit.target通过这个列表，您可以一目了然地定位到耗时最长的服务（如此例中的docker.service）,然后针对性地进行优化。
分析关键启动链（critical-chain）
某个服务耗时并非最长，但它处于启动的“关键路径”上，它的延迟会阻塞后续一系列服务的启动。critical-chain可以描绘出这条依赖链。
systemd-analyze critical-chain
输出会以树状结构展示从内核启动到最终目标（如multi-user.target）的依赖关系，并标注出每个节点的耗时,这对于理解服务间的依赖和排查由依赖引起的启动延迟非常有帮助。
生成启动过程的SVG图表
对于更直观的分析，systemd-analyze可以将整个启动过程生成一个可视化的SVG图表。
systemd-analyze plot > boot_analysis.svg
执行后，当前目录下会生成一个名为boot_analysis.svg的文件，您需要将此文件下载到本地，使用浏览器或图像查看器打开，图表会以图形化的方式展示每个服务在启动时间轴上的位置和耗时,非常直观。
挖掘详细的启动日志：journalctl
journalctl是systemd的日志管理工具，它接管了传统的syslog,通过它可以查看到从内核初始化到用户空间服务启动的完整日志。
查看本次启动的日志
-b或--boot参数用于筛选仅属于本次启动的日志。
journalctl -b
这个命令会输出大量的信息，从内核消息开始，按时间顺序记录了每一个服务的启动、停止、错误和警告等事件。
查看指定次数的启动日志
如果想查看上一次甚至更早的启动日志（系统发生过异常重启）,可以添加数字偏移量。
# 查看上一次启动的日志 journalctl -b -1 # 查看倒数第三次启动的日志 journalctl -b -2
这在排查非正常关机或重启原因时极为有用。
只查看启动过程中的错误信息
结合-p err（或--priority err）参数，可以只筛选出本次启动过程中的所有错误和警告信息,快速定位问题。
journalctl -b -p err
查看内核启动消息
如果您只关心内核级别的消息，比如硬件驱动加载情况，可以使用-k或--dmesg参数，它等效于传统的dmesg命令。
journalctl -k
查看开机自启的服务列表
了解哪些服务被设置为开机自启，是管理系统资源和安全性的重要一环。systemctl命令可以轻松实现这一点。
systemctl list-unit-files --type=service --state=enabled
这个命令会列出所有状态为enabled的服务单元文件。enabled意味着该服务已配置为在下次启动时自动运行。
以下是几种常见服务状态的说明：
| 状态 | 描述 |
|---|---|
| enabled | 服务已设置为开机自启。 |
| disabled | 服务未设置为开机自启，但可以手动启动。 |
| static | 服务本身不能单独启动，通常是被其他服务所依赖的。 |
| masked | 服务被完全禁用，无法手动或自动启动，是一种更强的禁用方式。 |
通过综合运用以上这些工具和命令，您就可以对CentOS系统的启动过程进行全面而细致的监控和分析，无论是简单的状态查询，还是复杂的性能瓶颈排查，这些方法都能提供强有力的支持,帮助您更好地管理和维护您的系统。
相关问答FAQs
问题1：我的CentOS系统启动变得非常慢，应该如何着手排查？
解答： 排查启动缓慢问题，建议遵循“由宏观到微观”的步骤，使用 systemd-analyze 命令获取一个总体的启动时间概览，了解是内核、initrd还是用户空间阶段耗时最长，核心步骤是运行 systemd-analyze blame，这个命令会列出所有服务的启动耗时并降序排列，让你能立刻锁定“嫌疑犯”——那些耗时最长的服务，找到可疑服务后（my-slow-app.service），再使用 journalctl -b -u my-slow-app.service 命令查看该服务在本次启动过程中的详细日志，分析其在启动时具体做了什么，为什么会卡顿，通过“定位耗时服务 -> 查看服务日志”这一流程,通常都能找到问题的根源。
问题2：journalctl -b 和 dmesg 命令在查看启动信息时有什么区别？
解答： 两者虽然都与启动信息相关，但侧重点和范围不同。dmesg 是一个传统的、专门用于查看和打印内核环形缓冲区（kernel ring buffer）内容的命令，它主要记录的是内核启动和运行过程中的底层消息，例如硬件检测、驱动程序加载、内核错误等，范围严格限定在内核层面，而 journalctl -b 是 systemd 提供的现代日志工具，它不仅包含了内核消息（等同于 dmesg 的内容），还记录了用户空间的所有系统和服务日志，systemd 自身、网络服务、应用服务等，可以说，journalctl -b 提供的是一个从内核到用户空间的、完整的、按时间顺序排列的启动全景视图，而 dmesg 只是其中专注于内核的子集，在现代CentOS系统中，推荐使用 journalctl -k 来替代 dmesg,以获得更统一和结构化的日志体验。