Process containment and cleanup
While DataMind Oda works, it starts real processes on your computer: commands it runs and terminal sessions it opens for itself. This page explains how Oda keeps a command and everything it starts together as one managed range, how it stops and cleans that work up, and what is different on each kind of computer.
What a command may change on your computer is limited separately. See Command sandboxing and approvals and Permissions, approvals and feature controls.
What a managed range is
- An ordinary command and a terminal session both start a program on your computer. Oda keeps that program and every process it starts in one managed range, so the whole piece of work can be stopped together.
- Stopping the work stops the whole range: Oda asks the processes to stop first, and after a short grace period it forces anything still running.
- A stop is safe to repeat. Once a range is gone, further stops do nothing.
- Oda treats work as finished only when it can prove that nothing in the range is still running. When it cannot prove that, it reports that it cannot, rather than guessing.
How containment depends on your computer
Oda prefers the strongest containment your computer can offer, and it checks that support while starting each command. When the check fails, that command runs under the fallback instead.
| Your computer | How Oda keeps the range | Worth knowing |
|---|
| Linux | A temporary range owned by your user session | If the system's process manager reports a state Oda cannot trust, the launch stops with an error instead of continuing. |
| Windows | A private helper holds the program in a range that ends when the helper closes | The program is created suspended, placed in the range and only then allowed to run. There is a very short moment between creating the process and placing it, and Oda does not claim that moment is fully closed. |
| macOS and other systems without the stronger options | The system's process groups, with a forced whole-tree stop | A process that leaves its group is not guaranteed to stop, and a lingering process can delay the wait for the range to empty. |
The support check runs again for each command, so when the computer's ability changes, later commands can move between the strong path and the fallback.
On the fallback, Oda records one note per app run saying that it is using weaker process containment, and the note names the reason, for example that this computer cannot provide the stronger kind.
Oda never runs a command a second time through the fallback: once the stronger path may have started a command, it is not replayed.
On Windows, background work stays out of sight
- The processes Oda starts for commands, and the helper it uses to stop a process tree, start with their windows hidden. A background command does not flash a console window or take focus from what you are doing.
- A program's own window is hidden too, as long as the program honours the system's start-hidden setting.
Stopping a command
- Ask, then force. Oda first asks the whole range to stop. Anything still running after a short grace period is forced to end.
- Repeatable. Asking again once the range is gone is harmless.
- Proof, not assumption. Oda waits for the range to be proven empty before it treats the work as stopped. When that proof cannot be had, Oda reports that it could not confirm the range is gone.
Terminal sessions Oda manages
A terminal session is one of Oda's own shells, not the terminal in your side panel, which is yours (The terminal). What Oda can do in a session is collected on Terminal sessions; the exact results of each action are on Terminal tools.
- Size and type. A session is created with its number of columns and rows and its terminal type, which the programs inside see as the
TERM setting.
- Resize refits. Resizing the view re-fits the text on screen. It does not restart the session or recreate anything running in it.
- A program is required. Oda refuses to open a terminal session that names no program to run.
- After exit, input is refused. Once a session's shell has exited, writing to it or resizing it is refused; nothing is silently dropped.
Signals to a terminal session
Oda can signal the work running in a session. Which signals are available depends on the system:
- On Windows, only interrupt, terminate and force are available. Suspend and hangup are not, and a request for them is refused.
- On other systems the wider set is available, suspend and hangup included.
- An interrupt on Windows arrives the way a Ctrl-C is typed, as keyboard input to the program running in the console.
- A force kill aimed at the shell itself is refused. To end a session, Oda closes it instead, which stops the shell and everything running in it. See Terminal sessions.
Busy, idle or unknown
Oda watches whether a session it manages is idle or busy, so it can tell quiet from working:
- The state is idle, busy or unknown, and idle is never assumed. An incomplete observation is not reported as idle; when Oda cannot be sure, the answer is unknown.
- Your input clears the evidence behind an earlier idle answer, so the state is only good until you type.
- Work that runs quietly still counts: a silent loop, a program waiting on input or a background job keeps the session busy until its prompt returns.
- A job you stop, for example with Ctrl-Z, keeps the session busy even after its prompt returns, until that work is resumed or ended.
- The watch works only for the plain interactive bash (version 4.4 or newer) and zsh sessions Oda can observe. Other shells, wrapped commands, custom signal traps or prompt handlers, and Windows report unknown.
- A report that a session is waiting for input is a hint, not proof.
When Oda exits
- When you quit Oda, it stops the processes it manages before leaving: every live range is ended in the same pass, and Oda's terminal sessions end with it.
- The same pass runs when Oda exits through an error it can catch, such as an uncaught error or a rejected promise, and Oda keeps the exit code it was given.
- The pass does not claim the ranges were emptied cleanly; it ends what it can and leaves.
- A forced kill, an out-of-memory stop or a crash below the app cannot be caught inside Oda. Those cases need the operating system, or an outside supervisor, to clean up.
How Oda tells processes apart
- Oda checks the running processes one snapshot at a time, not through a live monitor.
- It identifies a process by its id together with the time it started, so an id the system has since reused is never mistaken for the original process when Oda stops or signals something.
Questions, answered
What happens to the programs a command starts when I stop it?
They are stopped with it: Oda stops the whole managed range together. It asks the processes to stop first and forces anything still running after a short grace period.
What does the note about weaker process containment mean?
The computer could not offer Oda's stronger process containment for that command, so Oda fell back to the system's process groups, and the note names the reason. In this mode a process that leaves its group is not guaranteed to stop, and a lingering process can delay the wait for everything to end. Nothing needs fixing: the note says which mode was used and why. Oda records it once per app run.
What happens to running work when Oda quits or crashes?
When you quit Oda, or when it exits through an error it can catch, it stops the ranges it manages before leaving and keeps its exit code. A forced kill, an out-of-memory stop or a crash below the app cannot be caught inside Oda; those need the operating system, or an outside supervisor, to clean up.
Why are suspend and hangup unavailable on Windows?
Windows offers only interrupt, terminate and force to what runs in a session; suspend and hangup are not available there and a request for them is refused. An interrupt on Windows arrives the way a Ctrl-C is typed, as keyboard input to the program running in the console.
Why is a session's state unknown instead of idle?
Oda reports idle only when it can observe the session clearly, and an incomplete observation is never reported as idle. A shell other than the plain interactive bash or zsh sessions Oda can watch, a custom signal trap or prompt handler in your start-up files, and Windows all answer unknown.
Why does a session stay busy after its prompt returns?
A job you stopped, for example with Ctrl-Z, keeps the session busy even after its prompt comes back. The state stays busy until that work is resumed or ended.
Does a background command on Windows flash a window or take focus?
No. The processes Oda starts for commands, and the helper it uses to stop a process tree, start with their windows hidden. A program's own window is hidden too, as long as the program honours the system's start-hidden setting.
How does Oda know a command and its processes have really stopped?
Oda waits until the whole managed range is proven empty. The wait succeeds only on that proof; when the proof cannot be had, Oda reports that it could not confirm the range is gone instead of treating the work as stopped.
How sure is Oda when it reports a session waiting for input?
It is a hint, not proof. Oda reads it from the system's process information, and that reading can be incomplete. A session that only went quiet is not evidence that its command finished either.
Can input reach a terminal session that has already exited?
No. Once a session's shell has exited, writing to it or resizing it is refused; nothing is silently dropped. Open a new session instead.