classifier: skip Docker container processes to fix docker exec failure by varunsinghal29 · Pull Request #334 · qualcomm/userspace-resource-manager

Varun Singhal (varunsinghal29) · 2026-09-29T10:12:32Z

URM was moving Docker container init processes out of their docker-.scope cgroup, causing systemd to remove the empty scope and breaking docker exec with "can't open cgroup" error.

Add isContainerProcess() to detect container init processes by reading /proc//cgroup and skip them in shouldProcBeIgnored().

qualcomm-ai-code-review-assistant · 2026-09-29T10:13:57Z

Qualcomm AI Review

Click to expand Code Review

Reviewed Commits: b192511

b192511: classifier: skip Docker container processes to fix docker exec failure

URM was moving Docker container init processes out of their
docker-.scope cgroup, causing systemd to remove the empty
scope and breaking docker exec with "can't open cgroup" error.

Add isContainerProcess() to detect container init processes by
reading /proc//cgroup and skip them in shouldProcBeIgnored().

Signed-off-by: Varun Singhal varusing@qti.qualcomm.com

This PR adds logic to detect and skip Docker container init processes when deciding whether to classify/move a process, in order to avoid breaking docker exec (which fails if the container's systemd scope is torn down after the process is moved out of its cgroup).

Files Changed:

File	Lines Changed	Issues Found	Highest Severity
contextual-classifier/ContextualClassifier.cpp	+32 (new `isContainerProcess` method, call-site in `shouldProcBeIgnored`)	1	Medium
contextual-classifier/Include/ContextualClassifier.h	+4 (declaration)	0	-

Overview: The change is functionally reasonable and well-scoped, but the substring-based detection logic for identifying Docker container cgroup scopes is somewhat fragile. No critical/blocking issues were found.

[Functionality] Fragile substring matching for container-scope detection - Medium

In isContainerProcess, the check line.find("docker-") != std::string::npos && line.find(".scope") != std::string::npos only verifies that both substrings exist somewhere in the line, without validating their relative order or that they form a single contiguous token (e.g., docker-<CID>.scope). This could theoretically produce false positives on unusual cgroup path strings that happen to contain both substrings unrelated to a real docker scope, or false negatives if .scope appears before docker- in some other combined cgroup line format. A regex-based match anchored to the expected pattern (e.g., docker-[A-Za-z0-9]+\.scope) would be more robust.

Fixed Code Snippet:

#include <regex>
...
static const std::regex kDockerScopeRegex(R"(docker-[0-9a-fA-F]+\.scope)");
...
while(std::getline(cgroupFile, line)) {
    if(std::regex_search(line, kDockerScopeRegex)) {
        return true;
    }
}

⚠️ This review was generated using AI assistance. Please verify all suggestions before applying.

qualcomm-ai-code-review-assistant

Qualcomm AI Review

qualcomm-ai-code-review-assistant · 2026-09-29T10:13:57Z

+
+    std::ifstream cgroupFile("/proc/" + std::to_string(pid) + "/cgroup");
+    if(cgroupFile.is_open()) {
+        std::string line;
+        while(std::getline(cgroupFile, line)) {
+            if(line.find("docker-") != std::string::npos &&
+               line.find(".scope")  != std::string::npos) {
+                return true;
+            }
+        }
+    }


[Functionality] Fragile substring matching for container-scope detection - Medium

In isContainerProcess, the check line.find("docker-") != std::string::npos && line.find(".scope") != std::string::npos only verifies that both substrings exist somewhere in the line, without validating their relative order or that they form a single contiguous token (e.g., docker-<CID>.scope). This could theoretically produce false positives on unusual cgroup path strings that happen to contain both substrings unrelated to a real docker scope, or false negatives if .scope appears before docker- in some other combined cgroup line format. A regex-based match anchored to the expected pattern (e.g., docker-[A-Za-z0-9]+\.scope) would be more robust.

Fixed Code Snippet

#include <regex> ... static const std::regex kDockerScopeRegex(R"(docker-[0-9a-fA-F]+\.scope)"); ... while(std::getline(cgroupFile, line)) { if(std::regex_search(line, kDockerScopeRegex)) { return true; } }

URM was moving Docker container init processes out of their docker-<CID>.scope cgroup, causing systemd to remove the empty scope and breaking docker exec with "can't open cgroup" error. Add isContainerProcess() to detect container init processes by reading /proc/<pid>/cgroup and skip them in shouldProcBeIgnored(). CRs-Fixed: 4689720 Signed-off-by: Varun Singhal <varusing@qti.qualcomm.com>

qualcomm-ai-code-review-assistant · 2026-09-29T10:16:36Z

Qualcomm AI Review

Click to expand Code Review

Reviewed commit: ac90224 "classifier: skip Docker container processes to fix docker exec failure

URM was moving Docker container init processes out of their
docker-.scope cgroup, causing systemd to remove the empty
scope and breaking docker exec with "can't open cgroup" error.

Add isContainerProcess() to detect container init processes by
reading /proc//cgroup and skip them in shouldProcBeIgnored().

CRs-Fixed: 4689720

Signed-off-by: Varun Singhal varusing@qti.qualcomm.com"

This PR adds Docker-container detection to the ContextualClassifier so that container init processes (identified via /proc/<pid>/cgroup containing a docker-<CID>.scope entry) are skipped by URM's process-move/tuning logic, preventing breakage of subsequent docker exec calls.

File	Lines Changed	Issues Found	Highest Severity
contextual-classifier/ContextualClassifier.cpp	+33 (new `isContainerProcess`, call site in `shouldProcBeIgnored`)	1	Medium
contextual-classifier/Include/ContextualClassifier.h	+4 (new method declaration)	0	-

Overall the change is small and self-contained. A main concern is the fairly loose substring-based matching logic used to detect the docker scope line, which is worth a second look but is not a blocking correctness issue.

[Functionality] Substring-based docker scope detection may produce false positives

The detection logic checks whether a single cgroup line contains both "docker-" and ".scope" substrings anywhere in the line, without validating structure (e.g., that they are contiguous as docker-<CID>.scope). A cgroup line with unrelated content that happens to include both substrings (e.g., a path segment named similarly) could be misidentified as a container process, causing legitimate processes to be skipped by URM.

Consider using a more precise match, e.g., checking that .scope immediately follows the docker-<CID> pattern, or using a regex to validate the expected format.

Fixed Code Snippet:

// Example of tighter matching using find + suffix check
size_t dockerPos = line.find("docker-");
if(dockerPos != std::string::npos &&
   line.compare(line.size() - 6, 6, ".scope") == 0) {
    return true;
}

⚠️ This review was generated using AI assistance. Please verify all suggestions before applying.

qualcomm-ai-code-review-assistant

Qualcomm AI Review

qualcomm-ai-code-review-assistant · 2026-09-29T10:16:36Z

+    //   - CRI-O (OpenShift / k8s alternative): cgroup path contains "crio-<CID>.scope"
+
+    std::ifstream cgroupFile("/proc/" + std::to_string(pid) + "/cgroup");
+    if(cgroupFile.is_open()) {
+        std::string line;
+        while(std::getline(cgroupFile, line)) {
+            if(line.find("docker-") != std::string::npos &&
+               line.find(".scope")  != std::string::npos) {
+                return true;
+            }
+        }
+    }
+    return false;
+}
+
 int8_t ContextualClassifier::shouldProcBeIgnored(int32_t evType, pid_t pid) {
    if(evType == CC_APP_CLOSE) {
        return false;


[Functionality] Substring-based docker scope detection may produce false positives

The detection logic checks whether a single cgroup line contains both "docker-" and ".scope" substrings anywhere in the line, without validating structure (e.g., that they are contiguous as docker-<CID>.scope). A cgroup line with unrelated content that happens to include both substrings (e.g., a path segment named similarly) could be misidentified as a container process, causing legitimate processes to be skipped by URM.

Consider using a more precise match, e.g., checking that .scope immediately follows the docker-<CID> pattern, or using a regex to validate the expected format.

Fixed Code Snippet

// Example of tighter matching using find + suffix check size_t dockerPos = line.find("docker-"); if(dockerPos != std::string::npos && line.compare(line.size() - 6, 6, ".scope") == 0) { return true; }

Xinzheng Long (xinlon-z) · 2026-09-29T12:24:06Z

    LOGI(CLASSIFIER_TAG, "Successfully loaded static proc data");
 }

+int8_t ContextualClassifier::isContainerProcess(pid_t pid) {


I think the current name-based filtering is more of a Docker-specific workaround. Since systemd-run, systemd-nspawn, and other cgroup-managed workloads may run into the same issue, is there a more generic solution based on cgroup hierarchy rather than process/container names?

Yes, this is intentionally specific to Docker.
Consider this a hotfix for the issue reported in https://orbit/CR/4689720. A more generic solution (e.g. detecting any external cgroup manager, not just Docker) that we can track through #333 urm issue

rajulup · 2026-09-30T02:28:57Z

+    //   - containerd (k8s default runtime): cgroup path contains "containerd-<CID>.scope"
+    //   - CRI-O (OpenShift / k8s alternative): cgroup path contains "crio-<CID>.scope"
+
+    std::ifstream cgroupFile("/proc/" + std::to_string(pid) + "/cgroup");


can't we add this to a exclusion list that classifier already has, why whitelisting code needed?

rajulup

docker run
→ we Container(repo) created using this command (docker run -dit --name repro python:3.12-slim)
→ New container PID 2223 placed in system.slice/docker-bd04adaedc13.scope ✅

URM kicks in
→ Sees PID 2223 (python3 one)
→ Moves it to urm.slice/focused.apps ⚠️

docker-bd04adaedc13.scope is now EMPTY
→ systemd deletes the scope 🗑️

docker exec repro /bin/true
→ runc looks for PID 2223 at docker-bd04adaedc13.scope
→ SCOPE IS GONE 💥
→ "can't open cgroup: no such file or directory" ❌

so all docker images type we have add in blocker list. that's why come with this solution.

qualcomm-ai-code-review-assistant Bot reviewed Sep 29, 2026

View reviewed changes

Varun Singhal (varunsinghal29) force-pushed the docker-fix branch from b192511 to ac90224 Compare September 29, 2026 10:15

qualcomm-ai-code-review-assistant Bot reviewed Sep 29, 2026

View reviewed changes

Varun Singhal (varunsinghal29) mentioned this pull request Sep 29, 2026

CR: 4689720 | ContextualClassifier relocates OCI container init process into urm.slice/focused.apps, orphaning docker-<CID>.scope and breaking docker exec #333

Closed

Xinzheng Long (xinlon-z) reviewed Sep 29, 2026

View reviewed changes

Varun Singhal (varunsinghal29) requested review from Kartik Nema (kartnema) and rajulup and removed request for rajulup September 29, 2026 12:30

rajulup requested changes Sep 30, 2026

View reviewed changes

Varun Singhal (varunsinghal29) requested review from rajulup and Sarbojit Ganguly (sarbojit-g) September 30, 2026 08:53

Kartik Nema (kartnema) approved these changes Sep 30, 2026

View reviewed changes

rajulup approved these changes Sep 30, 2026

View reviewed changes

Varun Singhal (varunsinghal29) merged commit 455f2e5 into qualcomm:main Sep 30, 2026
16 of 18 checks passed

Kartik Nema (kartnema) linked an issue Sep 30, 2026 that may be closed by this pull request

CR: 4689720 | ContextualClassifier relocates OCI container init process into urm.slice/focused.apps, orphaning docker-<CID>.scope and breaking docker exec #333

Closed

Varun Singhal (varunsinghal29) deleted the docker-fix branch October 5, 2026 08:59

Navigation Menu

Repository navigation

classifier: skip Docker container processes to fix docker exec failure - #334

classifier: skip Docker container processes to fix docker exec failure#334
Varun Singhal (varunsinghal29) merged 1 commit into
qualcomm:mainfrom
varunsinghal29:docker-fix

Varun Singhal (varunsinghal29) commented Sep 29, 2026

Uh oh!

qualcomm-ai-code-review-assistant Bot commented Sep 29, 2026

[Functionality] Fragile substring matching for container-scope detection - Medium

Uh oh!

qualcomm-ai-code-review-assistant Bot left a comment

Uh oh!

qualcomm-ai-code-review-assistant Bot Sep 29, 2026

Uh oh!

qualcomm-ai-code-review-assistant Bot commented Sep 29, 2026

[Functionality] Substring-based docker scope detection may produce false positives

Uh oh!

qualcomm-ai-code-review-assistant Bot left a comment

Uh oh!

qualcomm-ai-code-review-assistant Bot Sep 29, 2026

Uh oh!

Xinzheng Long (xinlon-z) Sep 29, 2026

Uh oh!

Varun Singhal (varunsinghal29) Sep 29, 2026

Uh oh!

rajulup Sep 30, 2026

Uh oh!

Varun Singhal (varunsinghal29) Sep 30, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Conversation

Varun Singhal (varunsinghal29) commented Sep 29, 2026

Uh oh!

qualcomm-ai-code-review-assistant Bot commented Sep 29, 2026

Qualcomm AI Review

[Functionality] Fragile substring matching for container-scope detection - Medium

Uh oh!

qualcomm-ai-code-review-assistant Bot left a comment

Choose a reason for hiding this comment

Uh oh!

qualcomm-ai-code-review-assistant Bot Sep 29, 2026

Choose a reason for hiding this comment

Uh oh!

qualcomm-ai-code-review-assistant Bot commented Sep 29, 2026

Qualcomm AI Review

[Functionality] Substring-based docker scope detection may produce false positives

Uh oh!

qualcomm-ai-code-review-assistant Bot left a comment

Choose a reason for hiding this comment

Uh oh!

qualcomm-ai-code-review-assistant Bot Sep 29, 2026

Choose a reason for hiding this comment

Uh oh!

Xinzheng Long (xinlon-z) Sep 29, 2026

Choose a reason for hiding this comment

Uh oh!

Varun Singhal (varunsinghal29) Sep 29, 2026

Choose a reason for hiding this comment

Uh oh!

rajulup Sep 30, 2026

Choose a reason for hiding this comment

Uh oh!

Varun Singhal (varunsinghal29) Sep 30, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants