centos nohup日志为何丢失了

在 CentOS 上使用 nohup 时，日志“丢失”通常不是真的被删除了，而是被重定向方式、系统机制或运维策略“藏起来/截断/覆盖”了。下面按最常见原因 → 排查方法 → 解决建议来说明。

一、最常见原因（90% 情况）

1️⃣ 没有正确重定向输出

典型错误写法：

nohup ./app.sh

这样只会：

标准输出 → nohup.out
标准错误（stderr）仍然打到终端

如果终端关闭或程序异常，你可能误以为“日志没了”。

✅ 正确写法：

nohup ./app.sh > app.log 2>&1 &

或

nohup ./app.sh >> app.log 2>&1 &

2️⃣ nohup.out 不在你以为的目录

nohup.out 默认生成在“执行命令时的当前目录”

常见误区：

在 /root 执行，但你去 /home 找
用 systemd / cron 启动时，当前目录是 / 或 /root

查找：

find / -name nohup.out 2>/dev/null

3️⃣ 日志被覆盖而非追加

如果你用的是 > 而不是 >>：

nohup ./app.sh > app.log &

下次启动会清空日志

✅ 始终用：

>> app.log 2>&1

4️⃣ 程序自己做了日志轮转 / 重定向

很多程序（Java / Python / Go）：

自己写日志文件
或调用 logging / log4j
nohup.out 里几乎没有内容

✅ 检查程序自身日志目录，而不是 nohup.out

二、系统层面导致“日志丢失”

5️⃣ CentOS 7+ 的 systemd 吞掉 nohup

如果你是通过：

crontab
systemctl
ssh xxx "nohup ..."

那么：

SIGHUP 逻辑不同
输出可能直接进 journalctl

查看：

journalctl -u your-service

6️⃣ 磁盘满 / inode 满

日志“写不进去”

检查：

df -h
df -i

7️⃣ 日志被 logrotate 截断

CentOS 默认 logrotate 会：

重命名
压缩
删除旧日志

例如：

app.log → app.log.1.gz

8️⃣ 程序崩溃太快，没来得及写

如果进程：

启动即退出
或段错误

你可能只看到空文件

检查：

echo $?
dmesg | tail

三、推荐的“绝不丢日志”写法 ✅

✅ 最稳方案（生产推荐）

nohup ./app.sh >> /data/logs/app.log 2>&1 &

✅ 加时间戳（防止混淆）

nohup ./app.sh >> /data/logs/app_$(date +%F).log 2>&1 &

✅ 用 systemd（CentOS 7+ 最佳）

[Service]
ExecStart=/opt/app/app.sh
StandardOutput=append:/data/logs/app.log
StandardError=append:/data/logs/app.log

四、快速自查清单 ✅

你可以回答我这几个问题，我可以直接帮你定位：

你用的 CentOS 版本（6 / 7 / 8 / Stream）？
启动命令是怎么写的？
是用 nohup 直接跑，还是 systemctl / cron？
日志是 nohup.out 还是自定义文件？
程序是什么语言（Java / Python / Shell）？

我可以根据你的实际情况精准指出“为什么丢了”。