projectdiscovery/nuclei · error
max sleep count
Error message
max sleep count
What it means
instance.go installs maxBackoffSleeper(10) as the go-rod browser sleeper; every internal rod operation that waits (connecting to the browser, evaluating CDP calls) goes through it. After 10 sleeps (exponential 100ms-500ms, i.e. a few seconds total) the sleeper returns 'max sleep count', aborting whatever browser operation was pending. It almost always means Chrome started but its DevTools endpoint never became usable.
Solutions
- Kill stale chrome/chromium processes and retry the scan
- Give the container more shared memory and CPU (docker run --shm-size=1g, raise memory limits)
- Run fewer concurrent headless templates (-concurrency-limit, -headless-concurrency) so Chrome gets resources
- Use -system-chrome with a known-good installed browser as an alternative to the downloaded Chromium
Example fix
# before docker run --rm -it nuclei:v3 -tags headless -u file.txt # after docker run --rm -it --shm-size=1g --memory=2g nuclei:v3 -tags headless -u file.txt
Defensive patterns
Strategy: retry
Validate before calling
pkill -f 'chrome.*remote-debugging-port' 2>/dev/null || true # clear zombie browsers before a headless run
Try / catch
var berr *rod.ErrBrowser // or string-match on 'max sleep count'
if err != nil && strings.Contains(err.Error(), "max sleep count") {
// browser stall: back off, kill stale chrome, retry once
time.Sleep(5 * time.Second)
_ = exec.Command("pkill", "-f", "remote-debugging-port").Run()
return retryScan()
} Prevention
- Run headless containers with --shm-size=1g and adequate memory/CPU limits
- Cap headless concurrency so Chrome instances are not starved
- Clean up chrome processes after crashed runs; reaping zombies prevents port conflicts
When it happens
Trigger: Chrome process launches but stalls: starved CI containers, tiny /dev/shm, low file-descriptor limits, or a stale/zombie chrome holding the debug port. Any rod call that keeps failing fast burns one of the 10 backoff slots.
Common situations: Docker with default 64MB /dev/shm running headless Chrome; low-memory GitHub Actions runners; leftover chrome processes from a previous crashed run; concurrent nuclei instances fighting for CPU.
Related errors
- js must be at least 1
- the chrome browser is not installed
- attribute can't be empty
- cookie reuse enabled but cookie-jar is nil
- Element did not appear in the given amount of time
AI-assisted analysis of projectdiscovery/nuclei@265b3a3dec (2026-08-15).
Data as JSON: /api/errors/ed2ddf73b209a059.
Report an issue: GitHub.
Appendix: source
Thrown at pkg/protocols/headless/engine/instance.go:70
return i.engine.Close()
}
// SetInteractsh client
func (i *Instance) SetInteractsh(interactsh *interactsh.Client) {
i.interactsh = interactsh
}
// maxBackoffSleeper is a backoff sleeper respecting max backoff values
func maxBackoffSleeper(max int) utils.Sleeper {
count := 0
backoffSleeper := utils.BackoffSleeper(100*time.Millisecond, 500*time.Millisecond, nil)
return func(ctx context.Context) error {
if ctx.Err() != nil {
return ctx.Err()
}
if count == max {
return errors.New("max sleep count")
}
count++
return backoffSleeper(ctx)
}
}
View on GitHub (pinned to 265b3a3dec)