我来帮你拆解这两个实际遇到的问题，结合测试场景给你清晰的解释和解决方案：

1. 最直观方案为什么会生成空文件？ #

你第一个尝试的命令最终得到空的test.gz，核心问题出在进程组信号处理和缓冲机制的配合：

当你执行 tcpdump -l -i eth0 | gzip -c > test.gz 时，bash会把tcpdump和gzip放到同一个进程组里。当你按下Ctrl+C终止捕获时，系统会给这个进程组里的所有进程发送SIGINT中断信号：

• tcpdump收到信号后会立刻终止，但此时它捕获的部分数据可能还滞留在输出缓冲区里，没来得及写入管道
• gzip收到SIGINT后也会直接退出，不会把已经从管道读取到的缓冲数据写入到test.gz中，甚至可能还没来得及读取任何数据就终止了

另外，虽然你加了-l选项要求tcpdump使用行缓冲，但在部分系统/旧版本中，当标准输出是管道而非终端时，-l的行缓冲规则可能不生效，依然会用块缓冲，这会让更多数据滞留在tcpdump的缓冲区里，最终随着进程终止而丢失，导致压缩文件为空。

2. Debian Jessie下的可行解决方案 #

你用的后台子shell方案在Debian 9能正常运行，但Debian 8里出现Broken pipe错误，是因为Jessie版本的bash或tcpdump对后台进程的管道处理逻辑不同：把gzip放到后台后，bash可能会提前关闭管道的读端，导致tcpdump写管道时触发SIGPIPE错误。

这里给你三个可靠的解决方案，按推荐优先级排序：

方案一：使用-U选项强制行缓冲（优先推荐） #

tcpdump的-U选项比-l更严格，它会强制让tcpdump对输出使用行缓冲，不管标准输出是不是终端。直接配合管道使用即可：

tcpdump -U -i eth0 | gzip -c > test.gz

按下Ctrl+C后，tcpdump会把所有已捕获的行数据写入管道，gzip会在收到EOF后把缓冲的数据写入文件再退出，不会出现空文件的情况。

方案二：用stdbuf强制gzip无缓冲 #

如果你的tcpdump版本没有-U选项，可以用stdbuf工具修改gzip的缓冲行为，让它实时处理数据：

tcpdump -l -i eth0 | stdbuf -i0 -o0 -e0 gzip -c > test.gz

stdbuf -i0 -o0 -e0表示让gzip的标准输入、输出、错误流都使用无缓冲模式，数据会实时从tcpdump传递到gzip并写入文件，即使收到中断信号也不会丢失数据。

方案三：先写入临时文件再压缩（兼容性最强） #

如果上面两种方案都不适用，你可以先让tcpdump把数据写入临时文件，捕获完成后再压缩，这种方法在所有Debian版本都能正常工作：

# 后台运行tcpdump写入临时文件
tcpdump -i eth0 -w temp.pcap.tmp &
# 记录tcpdump的进程ID并等待它结束
TCPDUMP_PID=$!
wait $TCPDUMP_PID
# 压缩临时文件并删除原文件
gzip temp.pcap.tmp
mv temp.pcap.tmp.gz test.gz

内容的提问来源于stack exchange，提问作者Charly