清空日志文件前必须确认进程未独占打开，直接 truncate 或重定向清空正被 FileHandler 写入的文件会导致写入失败或丢数据；根本原因是 handler 持有原文件描述符且不监听大小变化，截断后仍向旧偏移写入，可能触发 Illegal seek 错误。
清空日志文件前必须确认进程未独占打开
直接 truncate 或重定向清空一个正被 logging.FileHandler 写入的文件，大概率导致后续日志写入失败或丢数据。根本原因是 Python 的 logging 模块默认使用带缓冲的普通文件对象，且不监听文件大小变化。如果底层文件被截断，而 handler 还在原偏移位置继续写，轻则乱码，重则触发 IOError: [Errno 29] Illegal seek（尤其在某些 Linux 文件系统上）。
实操建议：
- 优先改用
logging.handlers.RotatingFileHandler或TimedRotatingFileHandler，它们内置安全轮转逻辑，清空需求自然消失 - 若必须手动清空，先确保没有 Python 进程（包括后台服务、Jupyter kernel）正在用该 handler 写这个文件；可用
lsof -f -- /path/to/logfile（Linux/macOS）验证 - 不要用
echo "" > logfile或truncate -s 0 logfile直接操作，除非你已完全停掉日志写入方
用 Python 原生方式安全覆盖清空（需 handler 支持 reopen）
标准 FileHandler 不提供 reopen() 方法，但你可以手动 close + reopen 实现“软清空”：即关闭当前句柄、清空文件、再重新打开——前提是你的日志配置允许这么做，且没有其他线程/进程干扰。
示例代码片段（仅适用于单线程、可控场景）：
立即学习“Python免费学习笔记（深入）”；
import logging
handler = logging.getLogger().handlers[0] # 假设是第一个 FileHandler
if isinstance(handler, logging.FileHandler):
handler.close()
with open(handler.baseFilename, 'w'):
pass # 清空内容
handler.stream = open(handler.baseFilename, 'a') # 重新打开，保持追加模式
注意：
- 该操作不是原子的，中间存在极短时间窗口无日志写入，不适合高可靠性要求场景
- 多进程下完全不适用——子进程无法感知父进程对文件的操作
- 若 handler 启用了
delay=True，首次写入前 stream 为None，需额外判空
生产环境推荐：用 logrotate 配合 copytruncate
Linux 系统中，最稳妥的清空方案根本不在 Python 层，而是交给 logrotate。它支持 copytruncate 指令：先拷贝当前文件，再立即截断原文件。只要应用以 O_APPEND 方式打开（Python FileHandler 默认如此），后续写入会自动追加到已被清空的原文件末尾，零丢失、零中断。
仅使用 Python 将 Claw Code 虚拟化框架与 OpenClaw 集成，提供 184 种工具和 200 多条命令，用于安全分析和代码质量...
配置示例（/etc/logrotate.d/myapp）：
/var/log/myapp/app.log {
daily
missingok
rotate 30
compress
copytruncate
}
关键点：
-
copytruncate是唯一能在不停服务前提下“逻辑清空”的成熟方案 - 务必确认你的 Python 进程对日志文件使用的是追加模式（
mode='a'），这是默认行为，勿手动改成'w' - 避免在 Python 中调用
os.system('logrotate ...')，应由系统定时任务驱动
为什么不能用 os.remove() + open() 重建？
看起来简单：删掉旧文件，新建同名文件。但这是危险操作——FileHandler 持有的是旧 inode 的文件描述符，remove 后该 fd 仍有效，新 open() 创建的是全新 inode，handler 继续往旧 fd 写，数据实际进入已被删除的文件（磁盘空间不释放，直到 handler 关闭），而新文件始终为空。
现象通常是：
- 日志内容“消失”，但磁盘占用没变
- 用
lsof -p PID可看到类似deleted标记的文件条目 - 重启进程后才恢复正常
所以，任何涉及 os.remove() 或 os.rename() 的手动清理，都必须配套 handler.close() + 重新初始化整个 logger，成本远高于用 copytruncate。
真正麻烦的从来不是“怎么删”，而是“删完之后，正在写的那个指针还指在哪”。盯着 inode 和 fd，比盯着文件名重要得多。
