bug(wrap): add oom_score_adj to exec specs

This value can be forwarded from a CRI and ensures an appropriate OOM
score is set for processes in cases where high memory use is seen.

Signed-off-by: Alexander Merritt <alexander@edera.dev>

Author: alexandermerritt

src/config.rs

@@ -85,6 +85,9 @@ pub struct ExecutableSpec {
     /// Requires `no_new_privs = true`.
     #[serde(default)]
     pub seccomp: Option<SeccompFilter>,
+
+    /// An optional out-of-memory score adjustment value.
+    pub oom_score_adj: Option<i32>,
 }
 
 #[derive(Default, Debug, Serialize, Deserialize)]

src/runner.rs

@@ -211,6 +211,11 @@ impl CreateRequestBuilder {
         self
     }
 
+    pub fn set_oom_score_adj(mut self, score: i32) -> CreateRequestBuilder {
+        self.config.exec.oom_score_adj = Some(score);
+        self
+    }
+
     pub fn set_hostname(mut self, hostname: &str) -> CreateRequestBuilder {
         self.config.hostname = hostname.to_string().into();
         self

src/wrap.rs

@@ -639,6 +639,12 @@ impl Wrappable for CreateRequest {
 
         debug!("mount tree finalized, doing final prep");
 
+        // Ensure the process receives the desired out-of-memory score adjustment.
+        // If not specified, we do want to pro-actively set this value to the
+        // kernel-default of zero, else the subprocess inherits the styrolite
+        // oom score (which is typcially set to a very low value).
+        fs::write("/proc/self/oom_score_adj", self.exec.oom_score_adj.unwrap_or(0).to_string())?;
+
         // We need to toggle SECBIT before we change UID/GID,
         // or else changing UID/GID may cause us to lose the capabilities
         // we need to explicitly drop capabilities later on.