Deliver a repeatable supervisor record
See this course’s project requirements
A local supervisor for two harmless supplied Python scripts, with process IDs, captured output, return-code classification, timeout cleanup and a resource-limit decision record.
Keep your working files in your own notebook or software. Save a private description, checklist, and work link in My Proof.
What to include
- Produce an owned-child lifecycle record with actual PID and explicit control scope.
- Retain an explicit bounded command/context specification and pre-launch mode rejection.
- Create an actual stdout/stderr/return-code classification matrix for successful and failed modes.
- Demonstrate bounded timeout cleanup and retain accurate interrupted-task classification.
- Document elapsed-time evidence and a clear unimplemented-resource-controls boundary.
- Deliver the owned supervisor with dynamic observations, tested lifecycle branches, and explicit resource/platform limits.
Review and revise
Use these criteria to check your work and choose what to improve.
- The implementation or declared simulation follows the supplied contract and retains inspectable original inputs.
- Normal, boundary and rejected cases are recorded with expected versus observed results.
- The changed case has a correct explanation and does not rely on hidden state.
- The project includes source, outputs, instructions and honest tool, privacy and verification limits.
Want more background?
The idea in everyday life
owned_worker.py has harmless ok, fail, and slow modes. local_supervisor.py starts only that owned Python file, captures its small output, classifies return status, and cleans it up after a bounded timeout. test-processes.py runs five checks with no outside commands or accounts.
A process project includes exact owned commands, observed outcomes, cleanup evidence, and limits. Local synthetic workers do not establish behavior of production services or unrelated applications.
Deliver a repeatable supervisor record — original worked practice
A process project includes exact owned commands, observed outcomes, cleanup evidence, and limits. Local synthetic workers do not establish behavior of production services or unrelated applications.
owned_worker.py has harmless ok, fail, and slow modes. local_supervisor.py starts only that owned Python file, captures its small output, classifies return status, and cleans it up after a bounded timeout. test-processes.py runs five checks with no outside commands or accounts.
1. Step 1
Run python3 test-processes.py against the delivered files.
You should see: Five owned-process cases pass.
A process project includes exact owned commands, observed outcomes, cleanup evidence, and limits. Local synthetic workers do not establish behavior of production services or unrelated applications.
2. Step 2
Collect success, PID, failure, timeout cleanup, and unknown-mode rejection evidence.
You should see: The lifecycle branches are separately recorded.
A process project includes exact owned commands, observed outcomes, cleanup evidence, and limits. Local synthetic workers do not establish behavior of production services or unrelated applications.
3. Step 3
Keep actual dynamic PIDs/times in the observed column and avoid fixed expected numeric values for them.
You should see: The evidence does not invent repeatable system-assigned values.
A process project includes exact owned commands, observed outcomes, cleanup evidence, and limits. Local synthetic workers do not establish behavior of production services or unrelated applications.
4. Step 4
Deliver source, command record, resource decision, and honest platform/production limits.
You should see: A bounded local supervisor project.
A process project includes exact owned commands, observed outcomes, cleanup evidence, and limits. Local synthetic workers do not establish behavior of production services or unrelated applications.
What to finish
Deliver the owned supervisor with dynamic observations, tested lifecycle branches, and explicit resource/platform limits.
Watch for this
Treating synthetic local lifecycle evidence as production reliability or ignoring an observed lingering child.
How can I tell I understand it?
Demonstrate the rule: A process project includes exact owned commands, observed outcomes, cleanup evidence, and limits. Local synthetic workers do not establish behavior of production services or unrelated applications. Use the supplied variant to distinguish a changed result from a broken implementation.
Quick knowledge check
Answer all 3 questions. Get at least 2 right and the lesson completes automatically.
You’ll get an explanation for each answer. Signed in? Your results save to your account.
Pass the check. We’ll save the progress.
Answer all 3 questions above and get at least 2 right. You can review the explanations and try again.
Go to the knowledge checkTools, templates, and lesson sources
Tools and templates
Tools open in a new tab so you can keep your place here.
Sources and further reading
Explore the references behind this lesson.
Source & access notes · checked 2026-10-01
Relevant documented module/API behavior inspected during expansion authoring; actual execution evidence is recorded separately. No grant eligibility is established.
Access: Official page retrieved with the web reader on 2026-10-01. Documentation reading does not certify execution in every native tool or browser.
Reuse: Original local practice files, fictional data, worked examples and questions. Concepts paraphrased and linked; source exercises are not copied.
Source & access notes · checked 2026-10-01
Relevant documented module/API behavior inspected during expansion authoring; actual execution evidence is recorded separately. No grant eligibility is established.
Access: Official page retrieved with the web reader on 2026-10-01. Documentation reading does not certify execution in every native tool or browser.
Reuse: Original local practice files, fictional data, worked examples and questions. Concepts paraphrased and linked; source exercises are not copied.
Source & access notes · checked 2026-10-01
Relevant documented module/API behavior inspected during expansion authoring; actual execution evidence is recorded separately. No grant eligibility is established.
Access: Official page retrieved with the web reader on 2026-10-01. Documentation reading does not certify execution in every native tool or browser.
Reuse: Original local practice files, fictional data, worked examples and questions. Concepts paraphrased and linked; source exercises are not copied.
Report a problem with this lesson
Tell us what went wrong. Please leave out personal information and private project contents.