---
title: "Discussion on \"I ran headless browsers inside a 1.9 GB cgroup and got 8 OOM kills a day\" | Hashnode"
description: "Discussion on \"I ran headless browsers inside a 1.9 GB cgroup and got 8 OOM kills a day\". A year of \"just use Playwright in headless mode\" advice did not prepare me for the part nobody blogs about: the sandbox around the browser. I build automated agents that register accounts and post con"
url: "https://hashnode.com/posts/i-ran-headless-browsers-inside-a-1-9-gb-cgroup-and-got-8-oom-kills-a-day/6abbe3a4918553df8df07b90"
---

[Feed](https://hashnode.com/feed) /

Discussion

# [I ran headless browsers inside a 1.9 GB cgroup and got 8 OOM kills a day](https://techlabautohash.hashnode.dev/i-ran-headless-browsers-inside-a-1-9-gb-cgroup-and-got-8-oom-kills-a-day?utm_source=hashnode&utm_medium=feed)

A year of "just use Playwright in headless mode" advice did not prepare me for the part nobody blogs about: the sandbox around the browser. I build automated agents that register accounts and post con

Sep 29 · 6 min read · techlabautohash.hashnode.dev  
Read the article

-   [#systemd](https://hashnode.com/tag/systemd)
-   [#browser-automation](https://hashnode.com/tag/browser-automation)
-   [#playwright](https://hashnode.com/tag/playwright)
-   [#devops](https://hashnode.com/tag/devops)
-   [#memory-management](https://hashnode.com/tag/memory-management)

## Written by

[techtutorialshashnode8d89a8](https://hashnode.com/@techlabauto)

@techlabauto · Moscow, Russia

  
[View profile](https://hashnode.com/@techlabauto)

Notes on automating the web: Playwright, captchas, proxies and the pipelines around them.

I automate browser workflows and publish what actually breaks: Playwright scenarios, captcha solving, proxy rotation, anti-detect stacks. Real runs, real numbers, no theory.

## Responses 1

Markdown supported · ⌘↵ to post

[OnlineProxy](https://hashnode.com/@onlineproxyio)

[Sep 30](https://hashnode.com/posts/i-ran-headless-browsers-inside-a-1-9-gb-cgroup-and-got-8-oom-kills-a-day/6abbe3a4918553df8df07b90/comment/6abd3afffdc5eb9a66391c1c)

your command doesn't seem to set a memorymax on the browser unit, so oomploicy=stop probably won't do much. it might help to set the cap first, then the policy, and give each worker a unique unit name

you can check it with systemctl --user show on controlgroup, slice, memorymax and oompolicy. memory.oom.group isn't a systemd property, so that one you'd read from the sysfs folder for the controlgroup.

on the proxy lease post, execstoppost should still run after an oom kill, though it's worth testing on your systemd version. a host crash is the real hole there, so a lease ttl plus an independent reconciler is still a good idea