ulimit -f 不能防止日志无限扩容，它仅限制当前shell及其子进程单个文件累计写入字节数，对已运行服务、已打开文件无效，且无轮转能力。
ulimit -f 不能直接防止日志无限扩容，它限制的是进程通过 write() 系统调用写入单个文件时的**累计字节数上限**，且仅对当前 shell 及其子进程生效，不作用于已运行的服务（如 syslog、nginx、java 应用等），也不具备“日志轮转”或“按时间/大小自动截断”能力。
ulimit -f 的真实作用与局限
当一个进程尝试向一个文件写入数据，且该文件当前大小 + 待写入字节数 > ulimit -f 设置值（单位：KB）时，write() 调用会失败并返回 EFBIG 错误。此时进程是否停止写日志，取决于它自身是否检查并处理该错误：
- 多数标准工具（如
echo >> log.txt、logger）遇到EFBIG会报错退出或静默失败，但不会自动清空或轮转文件； - 守护进程（如
rsyslog、systemd-journald）通常忽略ulimit -f，因其启动时未继承用户 shell 的限制，且自身有独立日志管理逻辑； - 设置对已打开的文件描述符无效——若进程在 ulimit 设定前已打开日志文件，后续写入不受限。
真正有效的日志容量防护组合方案
单靠 ulimit -f 不足以防范日志膨胀，需结合以下机制：
-
服务级配置限流：例如
rsyslog中用$SystemMaxFileSize和$SystemMaxFiles控制单个日志文件大小与保留数量；systemd使用SystemMaxUse=和SystemMaxFileSize=（在/etc/systemd/journald.conf中）； -
日志轮转（logrotate）：为自定义脚本或应用日志配置
/etc/logrotate.d/规则，支持按大小（size 100M）、时间（daily）触发切割、压缩与删除； -
文件系统级防护：使用配额（
quota）限制用户或组可使用的磁盘空间，避免单个用户日志占满整个分区； -
运行时轻量补救：对临时调试场景，可配合
ulimit -f 10240（即 10MB）+stdbuf -oL启动命令，让简单脚本在写满后终止，但仅适用于短生命周期进程。
ulimit -f 的正确使用示例（仅限可控场景）
假设你运行一个调试用的 Python 脚本，将输出重定向到日志，并希望它写满 5MB 后停止：
ulimit -f 5120 # 单位 KB → 5MB python3 my_script.py > app.log 2>&1
注意：此设置只影响该行命令启动的整个进程树；若脚本内部用 open(..., 'a') 追加写，且未捕获 OSError: [Errno 27] File too large，Python 会抛出异常并退出。
排查与验证是否生效
可通过 prlimit 查看进程实际限制：
$ prlimit --as --fsize $PID | grep fsize FSIZE 5242880 5242880 bytes
也可用 strace -e write,openat 观察写入时是否返回 -EFBIG，但生产环境慎用。
