Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix logging.maxFileBytes config value not applied at gateway start (likely logger init race) [1 pull requests, 1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#71800•Fetched 2026-04-26 05:08:09
View on GitHub
Comments
0
Participants
1
Timeline
6
Reactions
0
Author
1OAKDesign1OAKDesign
Participants
1OAKDesign1OAKDesign
Timeline (top)
referenced ×5cross-referenced ×1

Setting `logging.maxFileBytes` in `~/.openclaw/openclaw.json` to a value above the default 500 MB is not picked up by the gateway logger. The default `DEFAULT_MAX_LOG_FILE_BYTES = 500 * 1024 * 1024` continues to apply across multiple gateway restarts (`launchctl bootout`+`bootstrap`), even though `openclaw config get logging.maxFileBytes` returns the configured value correctly.

Root Cause

Setting `logging.maxFileBytes` in `~/.openclaw/openclaw.json` to a value above the default 500 MB is not picked up by the gateway logger. The default `DEFAULT_MAX_LOG_FILE_BYTES = 500 * 1024 * 1024` continues to apply across multiple gateway restarts (`launchctl bootout`+`bootstrap`), even though `openclaw config get logging.maxFileBytes` returns the configured value correctly.

Fix Action

Fix / Workaround

Local workaround

PR fix notes

PR #71917: fix(logging): honor OPENCLAW_LOG_MAX_FILE_BYTES env override (#71800)

Description (problem / solution / changelog)

Summary

Fixes #71800.

logging.maxFileBytes set in ~/.openclaw/openclaw.json is silently ignored by the gateway logger when loadConfig() hasn't finished resolving by the first log write. The default DEFAULT_MAX_LOG_FILE_BYTES = 500 MB continues to apply across plist/launchd reboots even after openclaw config get logging.maxFileBytes reports the configured value.

This adds an env-var fast-path mirroring the existing OPENCLAW_LOG_LEVEL precedent: process.env.OPENCLAW_LOG_MAX_FILE_BYTES is read synchronously at logger init and beats the config-derived value when set. plist / launchd / systemd unit overrides therefore apply on the very first log write, regardless of config-load timing.

The reporter explicitly suggests this path as fix #3 in the issue.

Why env var, not lazy-init / config-loaded re-read

  • The race window is bounded but unpredictable across macOS launchd vs systemd vs Docker entrypoints. Re-reading on a config-loaded event would still leave a window where early errors emit at the wrong cap.
  • The logger already does cache invalidation on settingsChanged() per call, so the runtime path self-heals — but only if cfg is actually populated. In the reporter's repro, the cached miss persisted across 5+ bootout/bootstrap cycles, indicating the in-process requireConfig?.(\"../config/config.js\") path returns undefined for the synchronous logger init.
  • Env vars are guaranteed-resolved before any module-level read in this codebase (the existing OPENCLAW_LOG_LEVEL resolver depends on the same property).

Validation

inputresult
\"1073741824\"override applied
\"1024.7\"floored to 1024
\"\" / \" \"ignored, falls back to config / default
\"one-gig\" / \"0\" / \"-1\" / \"Infinity\" / \"NaN\"ignored

Tests: 4 new cases under src/logging/logger-env.test.ts \"OPENCLAW_LOG_MAX_FILE_BYTES (#71800)\".

Files

file+−
CHANGELOG.md10
src/logging/logger.ts190
src/logging/logger-env.test.ts870

Test plan

  • pnpm exec vitest run src/logging/logger-env.test.ts — 6/6 pass
  • pnpm exec oxfmt --check src/logging/logger.ts src/logging/logger-env.test.ts — clean
  • pnpm exec oxlint src/logging/logger.ts src/logging/logger-env.test.ts — 0 warnings/errors
  • CI green

Changed files

  • CHANGELOG.md (modified, +1/-0)
  • src/logging/logger-env.test.ts (modified, +146/-0)
  • src/logging/logger.ts (modified, +36/-0)
RAW_BUFFERClick to expand / collapse

Summary

Setting `logging.maxFileBytes` in `~/.openclaw/openclaw.json` to a value above the default 500 MB is not picked up by the gateway logger. The default `DEFAULT_MAX_LOG_FILE_BYTES = 500 * 1024 * 1024` continues to apply across multiple gateway restarts (`launchctl bootout`+`bootstrap`), even though `openclaw config get logging.maxFileBytes` returns the configured value correctly.

Environment

  • openclaw 2026.4.23 (verified); likely also affects 2026.4.22 and 2026.4.24 (not retested).
  • Host: macOS 26.3.1 (arm64), node 25.6.1 (gateway runs under embedded node 22.22.0).

Reproduction

  1. Set in `~/.openclaw/openclaw.json`: ```json "logging": { "maxFileBytes": 1073741824 } ```
  2. `openclaw config get logging.maxFileBytes` → returns `1073741824` ✓.
  3. `openclaw config schema` confirms `logging.maxFileBytes` is a valid top-level integer property ✓.
  4. Restart the gateway: `launchctl bootout gui/$UID/ai.openclaw.gateway && launchctl bootstrap gui/$UID ~/Library/LaunchAgents/ai.openclaw.gateway.plist`.
  5. Wait until `/tmp/openclaw/openclaw-<today>.log` exceeds 500 MB.

Observed: gateway emits `[openclaw] log file size cap reached; suppressing writes file=/tmp/openclaw/openclaw-<today>.log maxFileBytes=524288000`. The `maxFileBytes` printed is 524288000 (the default), not the configured 1073741824.

This persisted across 5+ bootout/bootstrap cycles spanning 4.22→4.23, 4.23→4.24, and 4.24→4.23 upgrades on the same host today.

Hypothesis

`dist/logger-DTX5koY3.js` reads:

```js function readLoggingConfig() { if (shouldSkipMutatingLoggingConfigRead()) return; try { const logging = ((requireConfig$1?.("../config/config.js"))?.loadConfig?.())?.logging; if (!logging || typeof logging !== "object" || Array.isArray(logging)) return; return logging; } catch { return; } } ```

…and the resolved settings:

```js let cfg = loggingState.overrideSettings ?? readLoggingConfig(); ```

Likely race: the logger initializes during very early gateway boot, before `loadConfig()` is fully resolved. `readLoggingConfig()` returns `undefined`, the resolver falls through to `DEFAULT_MAX_LOG_FILE_BYTES`, and the logger never re-reads after config finishes loading.

Suggested fixes

  • Re-evaluate `readLoggingConfig()` after the config-loaded event fires, or
  • Initialize the logger lazily on the first write, or
  • Expose `OPENCLAW_LOG_MAX_FILE_BYTES` env var so plist-level overrides work even when the config-load race exists.

Local workaround

Daily cron that truncates yesterday's `/tmp/openclaw/openclaw-YYYY-MM-DD.log` to 0 bytes. Bounds the noise without losing today's diagnostic value.

extent analysis

TL;DR

The issue can be fixed by re-evaluating the readLoggingConfig() function after the config-loaded event fires to ensure the logger picks up the configured logging.maxFileBytes value.

Guidance

  • Verify that the logging.maxFileBytes value is correctly set in the ~/.openclaw/openclaw.json file and that the openclaw config get logging.maxFileBytes command returns the expected value.
  • Consider implementing a fix that re-evaluates the readLoggingConfig() function after the config-loaded event fires to avoid the race condition.
  • As a temporary workaround, use a daily cron job to truncate yesterday's log file to 0 bytes to prevent excessive log growth.
  • Investigate exposing an OPENCLAW_LOG_MAX_FILE_BYTES environment variable to allow for plist-level overrides.

Example

No code example is provided as the issue is related to the timing of the readLoggingConfig() function and the config-loaded event.

Notes

The issue appears to be specific to the openclaw version 2026.4.23 and may also affect versions 2026.4.22 and 2026.4.24. The provided hypothesis suggests a race condition between the logger initialization and the config loading process.

Recommendation

Apply a workaround, such as the daily cron job, until a permanent fix can be implemented to re-evaluate the readLoggingConfig() function after the config-loaded event fires. This will help mitigate the issue and prevent excessive log growth.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#permission error#memory optimization#batch processing#GPU compatibility#latency issue

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING