Feature Request
Is your feature request related to a problem? Please describe.
This request is an optimization suggestion rather than a bug report.
ckb run works normally, but data/logs/run.log grows too large during long-running mainnet synchronization. A single continuously growing log file reduces troubleshooting efficiency because searching the whole file with tools such as grep becomes increasingly slow.
In actual operations, the approximate time of an incident is usually known in advance. If logs can be split into smaller files by time window, operators can inspect the file corresponding to the relevant period more directly.
Example environment:
- CKB:
0.205.0-rc2 (fd612aa 2026-03-09)
- Network:
mainnet
- Rich indexer:
Not Enabled
- Machine:
8C15G, Ubuntu 22.04.5 LTS, Intel(R) Xeon(R) Platinum 8275CL CPU @ 3.00GHz
- Sync start:
2026-03-10 20:20:08
From 2026-03-10 20:20:08 to 2026-03-11 17:00:00 (about 20h 39m 52s), data/logs/run.log had already grown to about 8.4 GB.
Describe the solution you'd like
Adding configurable log splitting for the log file generated by ckb run would improve operational usability.
By default, the current behavior could remain unchanged, with logs continuing to be written to a single run.log file.
For users who need it, CKB could provide configuration options in the CKB config file or command-line parameters for ckb run to enable log splitting and choose a splitting strategy. For example, logs could be split by time window, such as generating one log file per hour.
Describe alternatives you've considered
OS-level tools such as logrotate can partly address this requirement, but they require additional setup. Built-in support in ckb run would be more convenient.
Feature Request
Is your feature request related to a problem? Please describe.
This request is an optimization suggestion rather than a bug report.
ckb runworks normally, butdata/logs/run.loggrows too large during long-running mainnet synchronization. A single continuously growing log file reduces troubleshooting efficiency because searching the whole file with tools such asgrepbecomes increasingly slow.In actual operations, the approximate time of an incident is usually known in advance. If logs can be split into smaller files by time window, operators can inspect the file corresponding to the relevant period more directly.
Example environment:
0.205.0-rc2 (fd612aa 2026-03-09)mainnetNot Enabled8C15G,Ubuntu 22.04.5 LTS,Intel(R) Xeon(R) Platinum 8275CL CPU @ 3.00GHz2026-03-10 20:20:08From
2026-03-10 20:20:08to2026-03-11 17:00:00(about20h 39m 52s),data/logs/run.loghad already grown to about8.4 GB.Describe the solution you'd like
Adding configurable log splitting for the log file generated by
ckb runwould improve operational usability.By default, the current behavior could remain unchanged, with logs continuing to be written to a single
run.logfile.For users who need it, CKB could provide configuration options in the CKB config file or command-line parameters for
ckb runto enable log splitting and choose a splitting strategy. For example, logs could be split by time window, such as generating one log file per hour.Describe alternatives you've considered
OS-level tools such as
logrotatecan partly address this requirement, but they require additional setup. Built-in support inckb runwould be more convenient.