---
title: "Comment by OnlineProxy on \"I ran headless browsers inside a 1.9 GB cgroup and got 8 OOM kills a day\" | Hashnode"
description: "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,"
url: "https://hashnode.com/posts/i-ran-headless-browsers-inside-a-1-9-gb-cgroup-and-got-8-oom-kills-a-day/6abbe3a4918553df8df07b90/comment/6abd3afffdc5eb9a66391c1c"
---

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

Comment [I ran headless browsers inside a 1.9 GB cgroup and got 8 OOM kills a day](https://hashnode.com/posts/i-ran-headless-browsers-inside-a-1-9-gb-cgroup-and-got-8-oom-kills-a-day/6abbe3a4918553df8df07b90)

[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