谈国平刚接手一台新服务器时，我习惯先看一眼别人留下的启动命令。大多数情况都是 nohup ./run.sh &，然后日志就静静躺在 nohup.out 里。这个文件平时不起眼，可一旦线上出问题，它就成了唯一的救命稻草。而"稻草"之所以能救命，前提是你得真正搞懂 nohup 的日志输出规则——默认写在哪、怎么改、怎么切分、怎么避免文件无限膨胀。这篇就来把这些事一次性说透。
nohup 本身并不复杂，但围绕它的日志设置，新手踩坑率极高。我在不同项目组都见过同款事故：要么日志里啥都没记录，要么 nohup.out 被撑到几十个 G 把磁盘打满，要么因为重定向顺序写错导致报错信息完全丢失。所以这篇不只是列命令，我会把每个写法背后的机制、适用场景、以及实际运维中的注意事项一并拆开讲，希望你能直接照搬，并且能举一反三。
1. nohup默认把日志写到哪：先搞清那行提示的真正含义
很多人在终端执行 nohup ./app & 后，会看到一行字：nohup: ignoring input and appending output to 'nohup.out'。这行提示不是随便写的，它其实透露了两个关键信息：输入被忽略，输出被追加到 nohup.out。
1.1 nohup的工作本质：不只是"后台运行"
nohup 的全称是 no hang up，核心作用是让进程忽略 SIGHUP 挂断信号。当我们关闭终端窗口或 SSH 会话断开时，终端会向前台进程组发送 SIGHUP 信号，默认行为是终止进程。nohup 让进程无视这个信号，于是即使你关掉终端，程序依然在后台继续跑。
注意一点：nohup 本身不是"后台运行"命令，它只是屏蔽了挂断信号。真正让进程进入后台的，是命令末尾的 &。所以标准写法是 nohup command &，两者配合，才能做到"关掉终端也不死、不占当前终端输入"。
1.2 为什么默认是nohup.out而不是别的文件
当 nohup 发现自己启动的命令其标准输出（stdout）和标准错误（stderr）仍然指向终端时，它会自动把这两个输出流重定向到一个文件，这个文件默认就叫 nohup.out，保存在当前工作目录下。如果当前目录没有写权限，则会尝试写到用户主目录下的 nohup.out。
这个设计的初衷是：既然你要在后台长时间跑程序，输出不能让终端一直刷屏，也不能因为终端关闭就丢失，所以统一落到一个文件里。但它也带来了第一个坑：nohup.out 默认是追加写入，不是覆盖写入。也就是说，你第二次启动任务，新的输出会接在旧内容后面，不会清空原来的文件。这个"追加"机制对排查问题是有利的——历史日志不会丢，但文件也会因此越积越大。
1.3 stdout和stderr：两条流向决定了日志完整性
在 Linux 里，每个进程默认有 3 个文件描述符：
- fd 0 标准输入（stdin），默认指向键盘
- fd 1 标准输出（stdout），默认指向终端屏幕
- fd 2 标准错误（stderr），默认也指向终端屏幕
程序正常的运行日志、结果输出走 stdout，而错误信息、异常堆栈走 stderr。多数情况下两者最终都打印到终端，肉眼看不出去别。但在日志重定向时，这两条流是独立的管道，你可以让它们进两个不同文件，也可以合并进同一个文件。
如果只做 nohup command &，nohup 发现 stdout 和 stderr 都是终端，就会把二者都指向 nohup.out。所以默认情况下报错信息也在里面，不会丢。但如果后面我们手动做了部分重定向，情况就复杂了，下面细讲。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 把日志重定向到指定文件：顺序写错会让报错日志跑偏
默认的 nohup.out 虽然能用，但生产环境里我们通常希望能把日志放到指定目录、指定文件名下，方便清理，也方便和其他进程的日志区分开。这就涉及到 shell 的重定向语法。
2.1 标准写法：nohup命令加三个重定向符号
要让一个程序在后台运行并把所有输出写入 /data/logs/app.log，最常用的完整写法是：
bash复制nohup java -jar app.jar > /data/logs/app.log 2>&1 &
拆开看：
> /data/logs/app.log：把标准输出重定向到文件（覆盖模式）2>&1：把标准错误重定向到标准输出当前指向的位置，也就是同一个文件- 末尾的
&：让整个命令在子 shell 中后台运行
这种写法是最稳的，无论程序往 stdout 还是 stderr 写东西，最终都会进到同一个 app.log 里。
2.2 最容易踩的坑：2>&1写在了>前面
有个很经典的错误写法：
bash复制nohup java -jar app.jar 2>&1 > /data/logs/app.log &
看起来差不多，实际效果完全不同。2>&1 出现在 > 之前，它的含义是"把 stderr 指向 stdout 当前指向的位置"——此刻 stdout 还指向终端，所以 stderr 仍然会打印到终端。而此后的 > 只改了 stdout 的目标。最终结果：程序正常输出进了 app.log，但错误信息还在终端上，关了终端就彻底丢了。
判断规则不复杂：重定向是从左往右生效的，2>&1 必须写在所有修改 stdout 的重定向之后。如果拿不准，就按这个模板来：
bash复制nohup 命令 > 日志文件 2>&1 &
2.3 覆盖输出和追加输出的选择
> 是覆盖，>> 是追加。对日志文件来说，大多数场景应该用追加：
bash复制nohup python3 spider.py >> /data/logs/spider.log 2>&1 &
追加的好处是：如果这个脚本每天定时跑一次，所有日志都累积在同一个文件里，按时间串联查找方便。用覆盖的话，每次启动都会抹掉上一次的记录，排查历史问题时无从下手。
不过有一种情况我建议用覆盖：当程序自己内部有完善的日志库（如 logback、log4j2），并且已经按天按大小切分了文件，那么 nohup 这层重定向只会接收到程序的最外层启动日志，用 > 覆盖掉反而更干净，避免文件无限增长。
2.4 关于nohup.out不再生成的判断
有个常见问题：明明重定向了，nohup.out 还是被创建了。这通常发生在这种情况下——你只重定向了 stdout，没有重定向 stderr：
bash复制nohup java -jar app.jar > /data/logs/app.log &
此时 stdout 已经指向 app.log，不再指向终端，但 stderr 仍然指向终端。nohup 检测到 stderr 是终端，就会自动把它重定向到 nohup.out，于是文件依然出现。如果不想看到 nohup.out，务必把 2>&1 加上，让 stderr 也脱离终端。这一点在部署脚本里很关键，不然会出现"日志莫名写到了两个地方"的错觉。
3. 正常输出与错误输出分开落盘：排查故障时能省一半时间
合并输出是省事的做法，但有一种更讲究的玩法：把 stdout 和 stderr 分开两个文件。这样程序正常运行时的日志放在一个文件，报错信息放在另一个文件，排查问题时不用在几十 MB 的日志里翻找那几条 ERROR 记录。
3.1 用两个文件分别接收stdout和stderr
写法如下：
bash复制nohup node server.js > /data/logs/server.log 2> /data/logs/server-error.log &
这样一来，程序正常打印到 stdout 的内容进入 server.log，而任何写到 stderr 的错误堆栈进入 server-error.log。两个文件互不干扰。
不过实际操作中有个体验要提前说：很多框架（比如 Spring Boot）默认把 INFO 级别以上的日志全部打到 stdout，但 Error 级别的堆栈也是通过日志框架输出，不一定走系统级 stderr。换句话说，你分离开可能发现 server-error.log 几乎没内容，因为错误都被框架捕获后当作普通日志写到了 stdout。这种分离适合哪些场景呢？比较适合自己写的小脚本、临时任务，比如 Python 脚本用 print 输出普通信息、traceback.print_exc() 输出异常，那是真的很清晰。
3.2 用tail -f查看实时日志
无论合并还是分离，启动完服务后第一件事永远是确认日志在正常输出：
bash复制tail -f /data/logs/server.log
-f 参数会持续追踪文件新写入的内容，按 Ctrl+C 退出追踪，不影响后台进程本身。如果同时想看错误文件，可以开两个终端，或者用 tail -f server.log server-error.log 一次追两个文件，输出里会带文件名前缀，一眼能分辨来源。
一个小技巧：如果担心 tail -f 追的是已经被轮转掉的旧文件，加一个 -F 参数（大写）：
bash复制tail -F /data/logs/server.log
-F 会检测文件是否被重建（比如 logrotate 切割后生成了新文件），自动重新打开新文件继续追踪，比小写 -f 在日志轮转场景下省心得多。
3.3 手工给日志加时间戳和格式控制
nohup 本身不负责日志格式，它只是把进程的输出原样搬运到文件里。如果你希望每条日志前有时间戳，有两个思路：
第一个思路是写一个包装脚本，在调用真正命令前用 ts 命令给每行加时间戳：
bash复制nohup ./your_app 2>&1 | ts '[%Y-%m-%d %H:%M:%S]' >> /data/logs/app.log &
ts 命令在 moreutils 包里，Debian/Ubuntu 系通过 apt install moreutils 安装。这种方式适合标准输出本身就是纯文本的场景，比如 Node.js 或 Go 的普通日志。
第二个思路是直接在应用层配置：Java 程序用 logback/log4j2 的 pattern，Python 用 logging 的 Formatter，Nginx 用 log_format。这些都是程序自身的能力，nohup 只是它们的一个外层宿主。换句话说，想让日志"好看"，根本解决在应用层，不在 nohup 层。
4. "不生成nohup.out"的三种做法与各自代价
在不少真实场景里，业务方根本不需要 nohup 默认的日志文件。比如程序自己已经把日志写到了标准路径，外层再套一层 nohup.out 纯属冗余；又比如机器磁盘紧张，对日志不敏感的命令只希望静默执行。于是"如何不生成 nohup.out"成了高频问题。
4.1 直接丢弃输出：> /dev/null 2>&1
最粗暴的做法是：
bash复制nohup ./task.sh > /dev/null 2>&1 &
/dev/null 是一个特殊的空设备文件，任何写入它的数据都会被直接丢弃，不占磁盘空间。这个命令的意思是：标准输出和标准错误全部丢进黑洞，前台界面完全静默，也不生成任何日志文件。
适合场景：命令只是临时触发一下，比如 nohup touch /tmp/flag &，或者调用某个不关心结果的初始化脚本。但我不建议在核心服务上这么做——一旦程序启动后报错，你没有任何现场数据可查，只能重跑复现问题。
4.2 只保留错误日志，丢弃正常输出
如果还是想留一条后路，可以这么做：正常输出丢弃，错误输出保留。
bash复制nohup ./task.sh > /dev/null 2> /data/logs/task-error.log &
这样干净的同时，万一程序启动失败，错误信息还会记录到 task-error.log 里，不至于两眼一抹黑。这个方案很适合那些"正常情况下不打印任何内容，只有出错才输出"的命令行工具。
4.3 交给应用日志框架，完全不用nohup管理日志
还有一种更现代的思路是：连重定向都不做，依赖应用自身的日志框架。Java 系应用用 logback/log4j2 写文件，Python 应用用 RotatingFileHandler，Nginx 本身就是自己管理 access_log 和 error_log。这时候启动命令可以简化为：
bash复制nohup java -jar app.jar &
进程的 stdout 可能只输出启动横幅和少量信息，这些内容会进 nohup.out，但真正的业务日志全由应用自己写到独立文件。只要定期清理 nohup.out 即可。
这里有个容易被忽视的坑：即使应用有自己的日志框架，启动阶段如果发生 JVM 级错误（比如内存溢出、缺少依赖），这些错误往往直接走 stderr，而日志框架还没初始化完成。所以 nohup.out 最好还是保留着，不要轻易用 /dev/null 一起丢掉。线上故障现场，往往就藏在这些不起眼的早期输出里。
4.4 关于日志格式的延伸：nginx log_format其实是同款思路
很多人搜 nohup 日志设置时，会顺手搜到 nginx 日志格式配置。其实它们是同一个逻辑链条上的两个层级：nginx 的 log_format 是应用层定义"一行日志长什么样"，而 nginx 进程本身也可以用 nohup nginx & 启动，外层输出则走 nginx 的配置和 error_log。理解了这个分层，你就明白为什么说 nohup 只做搬运工，而格式设计要下沉到应用本身。
5. 日志无限增长的解决办法：手动切割与logrotate自动轮转
nohup.out 最让人头疼的问题不是生成，而是无限增长。我遇到过一台应用服务器，nohup.out 涨到 30 多 G，直接把数据盘撑满，引发连锁故障。原因很简单：没人设置轮转策略，程序又不停往 stdout 写东西。
5.1 快速手动切割：先复制再清空
如果日志已经很大，临时要处理，可以直接切割：
bash复制cp nohup.out nohup.out.$(date +%Y%m%d%H%M%S)
: > nohup.out
第二行的 : > nohup.out 是清空文件的技巧——冒号是一个内置空命令，把它的输出重定向到 nohup.out，等效于 cat /dev/null > nohup.out 或 truncate -s 0 nohup.out。这样运行中的进程仍然持有原文件句柄，继续写入时不会出错，新日志会追加到这个已被清空的文件里。
注意不要直接 mv nohup.out nohup.out.bak，因为进程还握着旧 inode，mv 之后进程仍然往旧文件写入，新文件反而不更新了。这就是运维里常说的句柄指向问题。copytruncate 的思路其实就是"复制当前内容，再截断原文件"，不改变 inode，进程感知不到任何变化。
5.2 logrotate实现自动轮转
生产环境建议用 logrotate 做定期轮转。在 /etc/logrotate.d/ 下新建一个配置文件，比如 app-nohup：
code复制/data/logs/app.log {
daily
rotate 7
compress
missingok
notifempty
copytruncate
dateext
}
参数含义：
daily：每天轮转一次rotate 7：保留最近 7 份轮转后的备份，更早的自动删除compress：备份文件用 gzip 压缩，节省空间copytruncate：先复制文件内容到备份，再截断原文件，适合不需要重启服务即可轮转的场景dateext：备份文件名带日期后缀，可读性好
配置完成后，可以用 logrotate -d /etc/logrotate.d/app-nohup 做一次预演，-d 是 debug 模式，不会真执行，只打印执行逻辑，确认无误后再用 logrotate -f /etc/logrotate.d/app-nohup 强制跑一次。
5.3 crontab做兜底清理
如果服务器没有 logrotate 或不想依赖它，也可以写一个简单的 crontab 脚本兜底。比如每天凌晨清理超过 500MB 的 nohup 日志：
bash复制0 2 * * * find /data/logs -name "nohup.out*" -size +500M -exec truncate -s 0 {} \;
注意这里用的是 truncate -s 0 而不是 rm，原因还是那句老话：进程持有旧的 inode，删除文件会导致进程继续向已删除的 inode 写入，磁盘空间不会真正释放。先截断文件，空间立刻回收，进程后续写入也正常。
这个"只截断不删除"的思路，是我处理所有外层日志的基本原则。理解它之后，无论面对 nohup.out 还是其他进程直接写文件的场景，你都不会因为磁盘空间告急而被迫重启服务了。
6. 从启动到治理：一个Java服务用nohup部署的完整示例
把前面所有知识点串起来，我用一个真实部署 Java 服务的例子来演示。假设有一个 Spring Boot 应用，打包产物是 app.jar，我们希望：
- 后台运行，终端关闭不退出
- 业务日志由 logback 自己写入
/data/logs/app/目录 - nohup 外层只保留启动阶段的 stdout/stderr，防止 JVM 早期错误丢失
- 外层日志按天轮转，防止磁盘膨胀
6.1 准备日志目录和启动脚本
先建好目录：
bash复制mkdir -p /data/logs/app
mkdir -p /data/logs/nohup
写一个启动脚本 start.sh：
bash复制#!/bin/bash
cd /opt/app
nohup java -Xms512m -Xmx1024m -jar app.jar \
--spring.profiles.active=prod \
> /data/logs/nohup/app-nohup.log 2>&1 &
echo $! > /opt/app/app.pid
echo "app started, pid: $(cat /opt/app/app.pid)"
echo $! 把启动后的进程 PID 存入 app.pid，后续停止服务时可以用 kill $(cat app.pid)。这一步非常实用，尤其是多实例部署时，靠 PID 文件精确定位要比 pgrep 猜进程靠谱得多。
6.2 验证日志输出
启动后立即确认：
bash复制tail -f /data/logs/nohup/app-nohup.log
Spring Boot 启动成功的标志是看到 "Started" 或 "Startup complete" 类似的日志。如果启动失败，异常堆栈会包含应用自己的业务日志信息，直接看这个文件即可。
如果 logback 配置正确，业务日志会在 /data/logs/app/ 下按天滚动，你需要配合查找的通常是 /data/logs/app/ 里的 ERROR 日志。两者分工明确：nohup.out 层管启动阶段的原始输出，logback 层管运行期业务日志。
6.3 为外层日志配置logrotate
由于应用自己轮转了业务日志，外层 nohup 日志内容其实不多，但稳妥起见还是做一个简单的轮转配置。新建 /etc/logrotate.d/app-nohup：
code复制/data/logs/nohup/app-nohup.log {
weekly
rotate 4
compress
missingok
notifempty
copytruncate
dateext
}
每周轮转一次，保留四周，足够覆盖大部分故障排查窗口期。这个文件独立于应用自身日志，逻辑上更干净，不会影响 logback 的滚动策略。
6.4 停止服务与日志留痕
停止服务时，不建议直接 kill -9，先尝试优雅停机：
bash复制kill $(cat /opt/app/app.pid)
如果进程在超时时间内未退出，再考虑强杀。停止后，把当前 nohup 日志备份一下：
bash复制cp /data/logs/nohup/app-nohup.log /data/logs/nohup/archive/app-nohup-$(date +%Y%m%d%H%M%S).log
这样每次发布或启动失败后，都留有一份当时的外层日志快照。后续复盘问题时，能精确对应版本、时间和启动状态，比盲目依赖系统级日志更直接。
6.5 我实际踩过的坑与你现在应该做的事
我在早期负责服务部署时，曾经因为 2>&1 的位置写错，导致 Spring Boot 启动线程报错信息完全消失，只能靠业务方打电话说"起不来"，然后我一遍遍手动执行命令复现。后来养成了一个习惯：每次启动完服务，先看日志文件大小和最后 50 行内容，确认不是 0 字节，确认没有异常堆栈，再离开操作台。这个习惯帮我挡掉了无数次"日志不落盘"的隐形问题。
如果你现在正被 nohup 日志困扰，我建议先做三件事：第一，查看当前是否有历史遗留的 nohup.out 文件，有的话统计大小，超 1GB 立刻截断；第二，把本次要启动的命令改成标准的 > 日志路径 2>&1 & 格式，显式指定文件位置；第三，检查日志目录所在磁盘剩余空间，没监控的话先用 df -h 手动看一眼。日志问题从来不是小事，它只是平时沉默，出事时给你最后一击。