drivers/executor: set oom_score_adj for raw_exec

[mattrobenolt]

This might not be wholly true since I don't know all configurations of Nomad, but in our use cases, we run some of our tasks as raw_exec for reasons.

We observed that our tasks were running with oom_score_adj = -1000, which prevents them from being OOM'd. This value is being inherited from the nomad agent parent process, as configured by systemd.

Similar to #10698, we also were shocked to have this value inherited down to every child process and believe that we should also set this value to 0 explicitly.

I have no idea if there are other paths that might leverage this or other ways that raw_exec can manifest, but this is how I was able to observe and fix in one of our configurations.

We have been running in production our tasks wrapped in a script that does: echo 0 > /proc/self/oom_score_adj to avoid this issue.

[mattrobenolt]

To add, we applied this patch to a production host, patched over 1.7.1 tag and it behaves as expected.

[shoenig]

Thanks @mattrobenolt! Hope you don't mind I've cleaned up the code just a bit and added an e2e test. Spot checking to make sure it works:

before:

➜ go test -v
=== RUN   TestRawExec
=== RUN   TestRawExec/testOomAdj
    assert.go:14:
        rawexec_test.go:28: expected string to contain substring; it does not
        ↪ substring: 0
        ↪    string: -999
--- FAIL: TestRawExec (4.01s)
    --- FAIL: TestRawExec/testOomAdj (3.83s)

after:

➜ go test -v
=== RUN   TestRawExec
=== RUN   TestRawExec/testOomAdj
--- PASS: TestRawExec (2.96s)
    --- PASS: TestRawExec/testOomAdj (2.77s)
PASS
ok      github.com/hashicorp/nomad/e2e/rawexec  2.962s

[mattrobenolt]

That's great! Thank you. :)

Do you know if this will be applicable for a 1.7.x release or need to wait for 1.8?

[shoenig]

It will go into the next 1.7.x bugfix release (1.7.3 assuming we don't get a CVE release before then)