fix: Allow tools running in the terminal to prevent the workspace from stopping due to idling

[vrubezhny]

This adds support for a CLI Watcher in che-machine-exec to prevent DevWorkspace idling when long-running CLI tools are running in the terminal.

The watcher is user-configurable via a '.noidle' YAML file. No admin privileges are required.

How configuration is resolved:

The '.noidle' file is located by searching in the following order:

• A path specified by the CLI_WATCHER_CONFIG environment variable
• Searching upward from the current project directory toward $PROJECTS_ROOT, looking for .noidle
• Falling back to $HOME/.noidle (e.g. ~/.noidle)
• If not found, CLI Watcher waits and checks again on the next poll

Example .noidle configuration:

enabled: true
watchedCommands:
  - helm
  - odo
  - sleep
checkPeriodSeconds: 60

Where:

• enabled: Enables or disables the CLI watcher (boolean)
• watchedCommands: List of command names to monitor
• checkPeriodSeconds: Polling interval in seconds (default is 60)

Benefits:

• Works entirely in user space — no container or cluster admin config needed
• Supports live updates (file can be added, edited, or removed while running)
• Helps avoid idle timeout disconnects during long-running CLI workflows
• Allows workspace authors to tailor idle behavior to specific tools

Issue: eclipse-che/che#23529

[azatsarynnyy]

👍

[tolusha]

@vrubezhny
Hi. Could you provide steps how I can test changes?

[akurinnoy]

Works as expected

[tolusha]

There is extremely rare case, but when SECONDS_OF_DW_INACTIVITY_BEFORE_IDLING is less than 60, then cli watcher doesn't prevent workspace from being stopped.

[vrubezhny]

@vrubezhny Hi. Could you provide steps how I can test changes?

To test it:

• I've built che-machine-exec docker image and published it at https://quay.io/repository/vrubezhny/che-machine-exec

• Then I've created a PR in che-code that uses my che-machine-exec image instead of the original one: [Draft] Test che-machine-exec with cli watcher che-incubator/che-code#567

• The che-code PR, after it was built on GH, had given me an image for the Che Code editor that I've used when creating a che DevSpaces WS on Sandbox

• Then, as comment say, I created the .noidle config file inside the Workspace project to track for sleep command running and then I was executing that command with different argument values + watching the log by tail -f /checode/entrypoint-logs.txt to see how che-machine-exec reacts on its presence.

[vrubezhny]

There is extremely rare case, but when SECONDS_OF_DW_INACTIVITY_BEFORE_IDLING is less than 60, then cli watcher doesn't prevent workspace from being stopped.

Yes, if the check for a command running happens with the less frequency that it may skip some activity events. One can configure .noodle to have checkPeriodSeconds's value less than SECONDS_OF_DW_INACTIVITY_BEFORE_IDLING 's one, but:

• Do we really need to have such a short Idling timeout (imho, it's not reasonable at all)
• Making the checks more frequent adds unnecessary load on the CPU/file read-write operations, etc.
• IMHO, setting the checkPeriodSeconds value to be 1/3 of SECONDS_OF_DW_INACTIVITY_BEFORE_IDLING would make it work fine

[azatsarynnyy]

@tolusha does the PR looks good for you?

[tolusha]

I would like to notice, that adding tail command to the config will prevent the workspace from being stopped despite the fact that user doesn't run this command.

[vrubezhny]

I would like to notice, that adding tail command to the config will prevent the workspace from being stopped despite the fact that user doesn't run this command.

Yes, tail is used to infinitely run the containers, so adding it to the config will always prevent a workspace from idling.
Do you want to add it as an exception (never take into account)?

[tolusha]

Maybe we can ignore /proc/1 as it is the main process

[vrubezhny]

Maybe we can ignore /proc/1 as it is the main process

ChatGPT says there are some caveats possible, like:

• If a container uses a sidecar pattern, there may be multiple “main-like” processes, but PID 1 still exists.
• Some orchestrators or custom entrypoints might wrap the main process with a shell or init system (tini, dumb-init). In that case, PID 1 is the wrapper, not your application binary.
• If the container has multiple process namespaces or is privileged, /proc/1 may not match the intended “main” process.

But probably yes - having /proc/1 excluded can make the trick in most cases and probably will not harm in the rest of the cases.