Default disable-dev-shm-usage=true may cause file-backed memory growth in long-running containerized workloads

Hi, We are using chromedp in a long-running containerized crawling service, and we found behavior that seems to be related to the default disable-dev-shm-usage=true in chromedp.DefaultExecAllocatorOptions.

Environment chromedp: v0.13.7 Chromium: Debian package 138.0.7204.157 Running inside Kubernetes / Linux containers /dev/shm is explicitly mounted as a memory-backed volume (tmpfs / emptyDir with medium: Memory) Browser workload is long-running and continuous, not a short-lived one-off automation task

Background We explicitly configured Chromium to use paths under /dev/shm:

chromedp.UserDataDir(userDataDir)
chromedp.Flag("disk-cache-dir", cacheDir)

where both userDataDir and cacheDir are under /dev/shm. However, our allocator was still built from:

opts := append(chromedp.DefaultExecAllocatorOptions[:],    
chromedp.UserDataDir(userDataDir),    
chromedp.Flag("disk-cache-dir", cacheDir),    // other flags...)

Later we checked the chromedp source and found that chromedp.DefaultExecAllocatorOptions includes: Flag("disable-dev-shm-usage", true) So even with a properly mounted and sufficiently large /dev/shm, Chromium was still started with --disable-dev-shm-usage. Symptoms before overriding this flag In our long-running workload, we observed: gradual container memory growth over time large values in cgroup memory.stat fields such as:

cache mapped_file dirty many Chromium runtime temp objects under /tmp

memory behavior that looked more like file-backed memory growth than pure anonymous RSS growth This was especially visible in cgroup accounting during continuous crawling. Workaround / fix We explicitly overrode the default option: chromedp.Flag("disable-dev-shm-usage", false) So the allocator became:

opts := append(chromedp.DefaultExecAllocatorOptions[:],
chromedp.Flag("disable-dev-shm-usage", false),
chromedp.UserDataDir(userDataDir),
chromedp.Flag("disk-cache-dir", cacheDir),

Result after overriding After doing this, we observed a clear improvement: Chromium temp objects under /tmp were significantly reduced dirty in cgroup memory.stat dropped close to zero file-backed growth (cache, mapped_file) became much less pronounced overall memory behavior became much more stable memory usage looked more like normal browser working set (rss + shmem) instead of slow file-backed growth In other words, the main problem was not that Chromium "used memory", but that a large part of runtime data seemed to fall back to more file-backed temporary paths instead of using /dev/shm normally. Question Is this expected behavior / tradeoff of the current default? I understand why disable-dev-shm-usage=true is useful for compatibility in many container environments with a very small default /dev/shm. However, for long-running containerized services where /dev/shm is explicitly mounted and sized properly, this default seems to have significant side effects. Would it make sense to document this more clearly in README / examples / best practices? For example: if users run long-lived browser workloads in containers and they explicitly mount a sufficiently large /dev/shm they may want to override: chromedp.Flag("disable-dev-shm-usage", false) to avoid falling back to a more file-backed temporary storage path. Why this matters This is probably not very visible in short-lived automation or test workloads. But in long-running containerized crawling / scraping services, this default can make memory behavior look like slow growth over time, even when browser instances are rotated or recreated regularly. Thanks.