如何在Linux中设置关机前的日志记录？shutdown命令与日志系统的整合技巧-LINUX-PHP中文网

答案：通过systemd服务单元或SysVinit脚本在关机前执行自定义日志脚本，记录系统状态并写入日志文件或系统日志。具体做法包括创建收集进程、网络、磁盘等信息的脚本，设置systemd服务确保其在关机早期运行，并通过logger发送关键信息至系统日志，同时应对超时、权限、磁盘只读等问题，实现故障诊断、安全审计和性能分析。

如何在linux中设置关机前的日志记录？shutdown命令与日志系统的整合技巧

在Linux系统中设置关机前的日志记录，核心思路是利用系统关机流程中的钩子（hooks），在系统真正关闭服务和文件系统之前，执行一个自定义脚本来捕获关键系统状态信息，并将其写入日志系统。这通常通过systemd服务单元或传统的SysVinit运行级别脚本来实现，确保这些日志能够被rsyslog或systemd-journald妥善记录。

解决方案

要实现关机前的日志记录，我们通常会创建一个自定义脚本，然后确保这个脚本在系统关机序列的早期阶段被执行。这里主要有两种现代Linux系统中的方法：

方法一：使用Systemd服务单元

这是目前主流Linux发行版（如CentOS 7/8, Ubuntu 16.04+等）推荐的方式。我们可以创建一个systemd服务单元，让它在

shutdown.target

登录后复制

、

reboot.target

登录后复制

或

halt.target

登录后复制

之前运行。

创建日志记录脚本： 首先，我们需要一个脚本来收集你关心的信息。例如，我们可以收集当前运行的进程、网络连接、磁盘使用情况以及内核消息。

创建一个文件，比如

/usr/local/bin/pre_shutdown_log.sh

登录后复制

：

#!/bin/bash
# 记录关机前的系统状态

LOG_FILE="/var/log/pre_shutdown_status.log"
TIMESTAMP=$(date +"%Y-%m-%d %H:%M:%S")

echo "--- System Shutdown Log Start: $TIMESTAMP ---" >> "$LOG_FILE"
echo "Running processes:" >> "$LOG_FILE"
ps aux --sort -rss >> "$LOG_FILE" 2>&1
echo "" >> "$LOG_FILE"

echo "Network connections:" >> "$LOG_FILE"
ss -tulnp >> "$LOG_FILE" 2>&1
echo "" >> "$LOG_FILE"

echo "Disk usage:" >> "$LOG_FILE"
df -h >> "$LOG_FILE" 2>&1
echo "" >> "$LOG_FILE"

echo "Last login/shutdown events:" >> "$LOG_FILE"
last -x >> "$LOG_FILE" 2>&1
echo "" >> "$LOG_FILE"

# 将关键信息也通过logger发送到系统日志，便于集中管理
logger -t "PRE_SHUTDOWN" "System is preparing to shut down. Detailed status logged to $LOG_FILE"
logger -t "PRE_SHUTDOWN" "Top processes by RSS: $(ps aux --sort -rss | head -n 2 | tail -n 1)"

echo "--- System Shutdown Log End: $TIMESTAMP ---" >> "$LOG_FILE"

登录后复制

给脚本添加执行权限：

sudo chmod +x /usr/local/bin/pre_shutdown_log.sh

登录后复制

创建Systemd服务单元文件： 在
```
/etc/systemd/system/
```
登录后复制
目录下创建一个新的服务文件，例如
```
pre-shutdown-logger.service
```
登录后复制
：
```
[Unit]
Description=Pre-shutdown System Status Logger
DefaultDependencies=no
Conflicts=shutdown.target reboot.target halt.target
Before=shutdown.target reboot.target halt.target
RequiresMountsFor=/var/log

[Service]
Type=oneshot
ExecStart=/usr/local/bin/pre_shutdown_log.sh
TimeoutStartSec=60 # 给脚本足够的时间执行，避免被过早终止
StandardOutput=journal
StandardError=journal

[Install]
WantedBy=shutdown.target reboot.target halt.target
```
登录后复制
这里有几个关键点：
- ```
DefaultDependencies=no
```
  登录后复制
  ：这很重要，它防止systemd自动添加一些默认依赖，确保我们的服务能在系统关机序列的早期，在大部分服务关闭前运行。
- ```
Conflicts=...
```
  登录后复制
  和
```
Before=...
```
  登录后复制
  ：明确指定此服务必须在关机、重启或暂停目标之前运行，并且与这些目标冲突，意味着它会在它们之前被触发。
- ```
RequiresMountsFor=/var/log
```
  登录后复制
  ：确保在执行脚本时，
```
/var/log
```
  登录后复制
  目录是可写的，因为我们的日志要写入那里。
- ```
Type=oneshot
```
  登录后复制
  ：表示这是一个一次性服务，执行完后就退出。
- ```
ExecStart
```
  登录后复制
  ：指定要执行的脚本。
- ```
TimeoutStartSec
```
  登录后复制
  ：设置脚本的执行超时时间，以防脚本卡住导致关机延迟。
- ```
StandardOutput=journal
```
  登录后复制
  ：将脚本的标准输出和错误输出也发送到systemd日志（journald），方便通过
```
journalctl
```
  登录后复制
  查看。
启用并启动服务：
```
sudo systemctl daemon-reload
sudo systemctl enable pre-shutdown-logger.service
```
登录后复制
```
enable
```
登录后复制
命令会在关机目标启动时自动拉起这个服务。

方法二：传统的SysVinit运行级别脚本（适用于旧系统或特定场景）

对于仍然使用SysVinit或需要兼容老旧系统的场景，可以在

/etc/rc0.d/

登录后复制

(关机) 或

/etc/rc6.d/

登录后复制

(重启) 目录下创建脚本链接。这些目录中的脚本会按照命名顺序（Snn开头的启动，Knn开头的停止）在进入对应运行级别时执行。

创建脚本： 同上一步骤的
```
/usr/local/bin/pre_shutdown_log.sh
```
登录后复制
。
创建软链接： 创建一个以
```
K
```
登录后复制
开头，数字较小（例如
```
K01
```
登录后复制
）的软链接，确保它在其他关机脚本之前运行。
```
sudo ln -s /usr/local/bin/pre_shutdown_log.sh /etc/rc0.d/K01pre_shutdown_log
sudo ln -s /usr/local/bin/pre_shutdown_log.sh /etc/rc6.d/K01pre_shutdown_log
```
登录后复制
这里的
```
K01
```
登录后复制
意味着在关机或重启运行级别中，这个脚本会作为“停止”服务的第一批被执行。

为什么关机前的日志记录如此重要？

在我看来，关机前的日志记录就像是系统在“临终”前留下的遗言。我们都遇到过服务器突然重启后，某些服务启动失败，或者系统在关机过程中卡住的情况。如果没有关机前的日志，我们就像是面对一个失忆的病人，无从得知它在失去意识前经历了什么。

百度智能云·曦灵

百度旗下的AI数字人平台

查看详情

具体来说，它提供了几个关键价值：

故障诊断和事后分析： 当系统出现非预期关机（比如电源故障，或者某个服务导致系统崩溃）或者关机后某些服务无法正常启动时，关机前的日志能提供最后时刻的系统状态快照。我们可以看到哪些进程还在运行、网络连接是否正常、磁盘空间是否充足等，这些都是诊断问题的宝贵线索。
安全审计和取证： 对于安全性要求高的环境，关机前的用户活动、网络连接甚至打开的文件列表，都能帮助安全团队在事件发生后进行取证分析，判断是否有恶意活动或异常行为在系统关闭前发生。
性能瓶颈识别： 如果系统在关机时耗时过长，关机前的日志可以揭示是否有某个进程长时间不响应，或者存在大量的I/O操作，从而帮助我们优化关机流程。
系统稳定性保障： 通过分析这些日志，我们可以更好地理解系统在不同负载下的关机行为，从而优化配置或服务启动/停止顺序，提升整体的系统稳定性。它就像一个黑匣子，记录着系统最后的“心跳”。

如何选择合适的日志内容和记录方式？

选择记录什么以及如何记录，这需要一些思考，毕竟我们不希望日志过多而拖慢关机，也不希望日志太少而失去价值。我的经验是，要抓住那些最能反映系统“健康状况”和“活跃状态”的关键指标。

合适的日志内容：

进程列表 (
ps aux --sort -rss
登录后复制
或
ps auxf
登录后复制
)：查看哪些进程在关机前还在运行，特别是那些占用资源较多或可能是僵尸进程的。
```
ps auxf
```
登录后复制
还能显示进程树，有助于理解父子进程关系。
网络连接 (
ss -tulnp
登录后复制
或
netstat -tulnp
登录后复制
)：检查系统在关机前是否有活跃的网络连接，哪些端口是开放的，哪些服务还在监听。这对于判断是否有外部连接或内部服务异常很有帮助。
磁盘使用情况 (
df -h
登录后复制
或
du -sh /path
登录后复制
)：快速了解文件系统空间是否充足，避免因磁盘满导致关机失败或日志无法写入。如果某个特定目录经常出问题，可以针对性地检查。
内核消息 (
dmesg
登录后复制
)：捕获最新的内核事件，可能包含硬件错误、驱动问题或OOM（内存不足）杀死的进程信息。
系统负载 (
uptime
登录后复制
或
top -b -n 1
登录后复制
)：了解系统在关机前的整体负载情况。
用户登录/关机历史 (
last -x
登录后复制
)：确认最后一次关机或重启是由谁触发的，以及是否有其他用户在关机前活跃。
打开的文件 (
lsof
登录后复制
)：在某些特定场景下，如果怀疑某个文件被锁定或占用导致关机问题，
```
lsof
```
登录后复制
可以提供有价值的信息。不过这通常会产生大量输出，需要谨慎使用或过滤。
特定应用状态： 如果你的服务器运行着数据库、Web服务器或其他关键应用，可以考虑在脚本中加入这些应用的简要状态检查命令（例如
```
systemctl status mariadb
```
登录后复制
或
```
nginx -t
```
登录后复制
）。

记录方式：

写入独立文件 (
>> /var/log/pre_shutdown_status.log
登录后复制
)：这是最直接的方式，将所有信息追加到一个专门的日志文件中。好处是集中、易于查找，且不受主日志系统配置影响。缺点是需要自行管理文件大小和轮转。
通过
logger
登录后复制
命令发送到系统日志：
```
logger -t "PRE_SHUTDOWN" "Your message here"
```
登录后复制
。这会将信息发送给
```
syslog
```
登录后复制
守护进程（如rsyslog或syslog-ng），由它来处理。好处是利用了系统已有的日志基础设施，可以根据
```
syslog
```
登录后复制
配置进行过滤、转发到远程日志服务器或写入不同的文件。缺点是如果信息量太大，可能会冲击主日志文件，且格式不如直接写入文件灵活。
通过
systemd-cat
登录后复制
发送到
journald
登录后复制
：如果你的脚本是systemd服务的一部分，并且你希望所有输出都进入
```
journald
```
登录后复制
，那么
```
StandardOutput=journal
```
登录后复制
已经做到了。如果你想在脚本内部发送特定消息到
```
journald
```
登录后复制
，可以使用
```
systemd-cat -t "pre-shutdown-script" echo "My custom message"
```
登录后复制
。

我个人倾向于结合使用：将详细的、可能包含大量输出的信息写入一个独立的、有时间戳的日志文件，而将关键的、摘要性的信息通过

logger

登录后复制

发送到系统日志，这样既能有详细记录，又能通过

journalctl

登录后复制

或

tail -f /var/log/messages

登录后复制

快速瞥见关键事件。

在实际部署中可能遇到的挑战及应对策略

在实际环境中部署关机前的日志记录，并非一帆风顺，总会遇到一些小麻烦。这就像你给系统装了个“黑匣子”，但有时这个黑匣子本身也会遇到问题。

挑战一：脚本执行超时或被过早终止

问题描述： 系统在关机过程中，会逐步停止服务。如果我们的日志脚本耗时过长，或者被其他依赖关系过早地终止，可能导致日志记录不完整或失败。
应对策略：
- 精简脚本： 只记录最关键、最必要的信息，避免执行耗时长的命令。例如，
```
lsof
```
  登录后复制
  在文件数量多时会非常慢，可能需要避免或进行严格过滤。
- 设置合理的超时： 在systemd服务单元中，
```
TimeoutStartSec
```
  登录后复制
  参数非常关键。确保它足够长，能让脚本完成工作，但又不能太长以至于显著延迟关机。
- 调整依赖关系： 确保你的systemd服务单元设置了正确的
```
Before=
```
  登录后复制
  和
```
DefaultDependencies=no
```
  登录后复制
  ，让它在大部分服务关闭之前运行。

挑战二：磁盘I/O问题或文件系统已只读

问题描述： 在关机后期，文件系统可能会被挂载为只读模式，或者如果系统本身因为磁盘故障而关机，日志可能无法写入。
应对策略：
- 尽早写入： 确保日志脚本在文件系统变为只读之前执行。systemd的
```
RequiresMountsFor=/var/log
```
  登录后复制
  有助于确保
```
/var/log
```
  登录后复制
  仍可写。
- 远程日志： 对于关键系统，考虑将关机前的关键日志信息通过
```
logger
```
  登录后复制
  命令发送到远程
```
syslog
```
  登录后复制
  服务器。这样即使本地磁盘完全损坏，日志也能被保存下来。
- 检查磁盘空间： 在脚本开头加入
```
df -h /var/log
```
  登录后复制
  检查，如果磁盘空间不足，可以尝试将日志写入
```
/dev/shm
```
  登录后复制
  （内存文件系统）然后通过
```
logger
```
  登录后复制
  发送关键信息。

挑战三：权限问题

问题描述： 脚本需要读取各种系统信息（如
```
/proc
```
登录后复制
目录下的文件、各种日志），并写入
```
/var/log
```
登录后复制
。如果权限配置不当，脚本可能无法正常工作。
应对策略：
- 以Root权限运行： systemd服务通常以root权限运行，这是最简单的解决方案。确保你的脚本本身拥有执行权限 (
```
chmod +x
```
  登录后复制
  )。
- 检查目录权限： 确保日志文件所在的目录 (
```
/var/log
```
  登录后复制
  ) 对写入是可用的。

挑战四：日志量过大，占用过多资源或难以分析

问题描述： 如果脚本收集的信息过于详细，可能导致日志文件迅速膨胀，或者在分析时难以从中提取关键信息。
应对策略：
- 选择性记录： 再次强调，只记录那些真正有助于诊断的信息。例如，
```
ps aux
```
  登录后复制
  已经足够，不需要再加
```
pstree
```
  登录后复制
  。
- 日志轮转： 如果你将日志写入独立文件，需要配置
```
logrotate
```
  登录后复制
  来管理这些文件的轮转和清理，避免它们无限增长。
- 摘要与详细分离： 如前所述，将关键摘要通过
```
logger
```
  登录后复制
  发送到系统日志，详细信息写入独立文件，这样可以根据需求选择查看。

挑战五：脚本本身的调试困难

问题描述： 调试一个在关机过程中运行的脚本是很麻烦的，因为你无法实时交互。
应对策略：
- 充分测试： 在非生产环境（如虚拟机或测试服务器）上进行充分测试。
- 输出重定向： 在脚本中加入
```
set -x
```
  登录后复制
  ，并将脚本的输出重定向到一个临时文件，例如
```
ExecStart=/bin/bash -x /usr/local/bin/pre_shutdown_log.sh > /tmp/pre_shutdown_debug.log 2>&1
```
  登录后复制
  。这样可以在下次启动后检查调试输出。
- 逐步添加： 不要一次性写一个大脚本，可以先从记录一行简单的信息开始，确认机制正常工作后，再逐步添加更多内容。