[Bug] Dashboard spawns leftover docker logs --tail processes, dockerd CPU spikes to 88% and stays there

[wayne0926]

Contact Information

wran@outlook.it

1Panel Version

v1.10.34-lts

Problem Description

CPU was pegged at 100% on my server. Found 24 leftover processes from 1Panel running docker logs --tail 30 against all containers and grepping for error keywords. dockerd was at 35-88% CPU doing ~637k read syscalls/sec with near-zero actual I/O — polling log file descriptors in a loop. Killing those processes dropped CPU from 100% to ~6% instantly.

The processes were spawned on Apr24 with no active dashboard session at the time. PPID was 1 (orphaned after the parent web handler exited). They just accumulate and never clean up.

Steps to Reproduce

Not sure how to reliably trigger it — I wasn't actively doing anything when it happened. But the script 1Panel runs looks like:

timeout 120 docker ps --format 'table {{.Names}}\t{{.Status}}\t{{.Ports}}' 2>/dev/null && echo '==ERROR LOGS==' && docker ps --format '{{.Names}}' 2>/dev/null | head -10 | while read c; do docker logs --tail 30 "$c" 2>&1 | grep -iE 'error|fail|exception|critical|warn' | tail -5; done

Probably triggered by dashboard load or background monitoring. The problem is these processes pile up and don't terminate properly.

The expected correct result

• Don't scan container logs automatically unless the user explicitly asks, or
• Make sure processes actually terminate and close their fds, or
• Give users a setting to disable this — on a single-core VPS running docker logs --tail 30 across all containers simultaneously is destructive

Related log output

# dockerd at peak load
PID     %CPU  COMMAND
3145844 35-88 dockerd   (fluctuates, spikes when logs processes are active)

# System-level CPU breakdown
%Cpu(s): 53.4 us, 46.6 sy,  0.0 ni,  0.0 id,  0.0 wa
# 46.6% system CPU with 0% idle — dockerd was consuming the entire core

# dockerd I/O stats (3-second sample, observed around 20:35 CST)
syscr: 135357722361 -> 135359633625  (+1,911,264 read syscalls = ~637k/sec)
rchar: 117951608    -> 117951641     (+33 bytes actually read = near-zero)
read_bytes: 233037824 (unchanged, no actual disk I/O)
# This confirms dockerd was polling container log file descriptors
# in a tight loop, not doing real I/O

# Process tree of the orphaned workers
PID 4141078 (PPID=1, orphaned — original parent was 1Panel web handler)
  └─ PID 4141088
       └─ docker logs --tail 30 1Panel-bitwarden-Zkt1
       └─ docker logs --tail 30 1Panel-maddy-mail-LCO7
       └─ docker logs --tail 30 1Panel-roundcube-EXLr
       ... (one per container, 16 containers total)
# 24 such processes were alive, some already 2 days old (since Apr24)
# All in S (sleeping) state but dockerd still burning CPU on fds

# Server environment
1 vCPU, 1.9GB RAM, 1GB swap (814MB used)
Debian 12 (kernel 6.1.0-44), Docker 29.4.1, overlay2 storage
json-file log driver (max-size 50m, max-file 3)
16 Docker containers running

# 1Panel DB settings
MonitorStatus = enable
MonitorInterval = 5  (default)

Additional Information

• Workaround: cron job running pkill -f "docker logs.*--tail" every 5 minutes — drops CPU from 100% to ~6% immediately
• Also set MonitorInterval from 5 to 60 in the database, but unsure if that helps with this specific issue
• Related: Issue [BUG]清空容器日志，dockerd进程CPU占用异常 #1999 — similar scenario about clearing container logs causing dockerd CPU spike
• Forum: https://bbs.fit2cloud.com/t/topic/3905 — might be related, someone reported 1Panel consuming high CPU

[wanghe-fit2cloud]

感谢反馈。我们检查了当前代码逻辑，暂未发现 Dashboard 会自动执行上述 docker logs --tail 30 并扫描所有容器日志的逻辑。

建议先升级到 1Panel v2 版本后观察是否还会出现该问题。与此同时，我们也会在本地环境重点验证你提到的 docker logs 进程残留问题，确认是否存在日志读取超时后未正确清理子进程的情况。