<system> umask` / `--umask` is not applied to worker-created files under a foreground supervisor
维护者通常 1 天内回复
@mbmtbtbc 已经在做这个了。
开始于 2026年7月15日。
评估
调研方向
跟踪 --umask 和 umask 如何流经前台 supervisor 和 ServerEngine，重点关注 worker_chumask 入口点以及文件缓冲区块的创建。比较 --no-supervisor、受监督的 --daemon 和受监督的前台行为，然后添加测试覆盖或文档，使前台 worker 要么遵循配置的 umask，要么明确记录该模式的限制。
由索引模型根据 Issue 内容生成。
描述
Is your feature request related to a problem? Please describe.
Follow-up from #5390, and related to #4816
Both --umask and <system> umask set the process umask, but the effect on worker-created files (e.g. file buffer chunks) depends on the run mode:
--no-supervisor(standalone): applied — Fluentd callsFile.umaskdirectly in the worker.- Supervised +
--daemon(daemonize, e.g. fluent-package): applied — ServerEngine sets the umask before spawning workers, so workers inherit it. - Supervised without
--daemon(foreground): not applied — ServerEngine's non-daemonize path doesn't callFile.umask, and Fluentd doesn't passworker_chumask, so workers keep the inherited (shell) umask.
Verified on all three modes: a file buffer chunk created with umask 0077 is 0600 under --no-supervisor and --daemon, but stays 0644 when running fluentd -c fluent.conf in the foreground.
This is existing behavior, not a regression from #5390. Opening this to decide whether to close the gap (e.g. by passing worker_chumask to ServerEngine so foreground workers honor the umask too) or to document it as a known limitation of the run mode.
Describe the solution you'd like
Make --umask / <system> umask also apply to worker-created files under a foreground supervisor (e.g. by passing worker_chumask to ServerEngine so workers set their umask explicitly rather than relying on inheritance)
Describe alternatives you've considered
If the current behavior is intentional, document the per-mode applicability instead, so foreground-supervisor users don't expect it to affect buffer file permissions.
Additional context
No response
- 主要语言
- Ruby
- 星标
- 13.6k
- 派生
- 1.4k
- 平均合并
- 16 小时 41 分钟
- 30 天内合并 PR
- 70
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
fluent/fluentd 的其他 Issue
-
out_forward: unacknowledged chunks are resent forever with heartbeat_type none, ignoring retry limits and secondary可能已有人在做 关联的 PR 仍在进行中或已合并。 未关闭bug
难度 3/5 1-2 天 新手友好度 74/100
维护者通常 1 天内回复
-
bug
难度 4/5 3-5 天 新手友好度 42/100
维护者通常 1 天内回复
-
bug enhancement
难度 5/5 一周以上 新手友好度 35/100
fluent/fluentd#5494 · 2 条评论 · 1 个 reaction ·
维护者通常 1 天内回复
-
BufferChunkOverflowError inside @ERROR loops forever - no buffer parameter can stop it可能重新可做 关联的 PR 已关闭且未合并。 未关闭bug
难度 4/5 3-5 天 新手友好度 48/100
维护者通常 1 天内回复
-
enhancement
难度 5/5 一周以上 新手友好度 25/100
维护者通常 1 天内回复
相似的 Issue
-
难度 2/5 1-3 小时 新手友好度 82/100
-
难度 2/5 1-3 小时 新手友好度 68/100
metanorma/metanorma-cli#494 ·
维护者通常 1 天内回复
-
难度 1/5 1 小时以内 新手友好度 91/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 76/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 86/100
维护者通常 1 天内回复