erix/posixd
Watch
1
0
Fork
You've already forked posixd
 0
generated from erix/meta
Code Issues 5 Pull requests 1 Projects Releases Packages Wiki Activity Actions

[FEATURE] Implement real fork, exec, wait, signals and terminal process groups #3

New issue
Open
opened 2026-09-12 07:56:26 +02:00 by erikinkinen · 0 comments
erikinkinen commented 2026-09-12 07:56:26 +02:00
Owner
Copy link

Problem and motivation

Build processes and shell job control require real process snapshots, replacement, child status and signal delivery. Descriptive subshell state or spawn-only substitutes do not establish fork semantics or safe process control.

Proposed behavior and scope

Implement correctness-first fork, atomic publication/unwind, exec replacement, required spawn actions, wait/zombie retirement, signal state and handlers, groups/sessions and real resource counters. Validate concurrent children, threaded fork, descriptor inheritance, terminal control and exhaustion recovery.

This issue records planned work; its unchecked criteria are not implementation proof. The normative basis is Phase 6 and AC1–AC24.

Authority, security and reliability

Duplicate only authorized memory and descriptor rights; never copy private service receive authority. Bind signal/group/child operations to live generations inside the realm, validate restored CPU state, and retire descendants and pending exceptional grants on failure or termination.

Apply the priority order: security, reliability, then performance. Keep suspected vulnerabilities in the repository’s restricted SECURITY.md reporting channel.

Acceptance criteria

  • Specify fork's exact snapshot, return values, native generation, POSIX PID, shared
    open descriptions and allowed capability inheritance. A shell's descriptive subshell
    checkpoint is not a process fork.
  • Implement correctness-first private address-space copying unless a separately
    reviewed copy-on-write mechanism is justified; duplicate only selected memory/descriptor
    rights, never a service's private receive authority.
  • Implement atomic child publication and full unwind for allocation, mapping,
    transfer or startup failure; parent state remains usable and no half-started child or leaked
    authority remains.
  • Implement execve/exec-family replacement using exact executable identity, manifest,
    realm policy, argv/env, inherited descriptors and signal rules; success replaces the image,
    failure preserves the prior process.
  • Implement posix_spawn/file actions if required by imported tools; preserve the same
    inheritance/security semantics and test fork/exec equivalence where specified. Do not fake
    fork by always taking a spawn-only path.
  • Implement wait/waitpid and required wait options with exact child status, zombie
    retirement, multiple waiters, interruption and PID reuse safety.
  • Implement process groups/sessions and terminal foreground ownership entirely within
    delegated namespaces; numeric group IDs cannot grant control.
  • Implement sigaction, masks, pending delivery, default/ignore/caught dispositions,
    unblock ordering and supported signal sets with explicit state.
  • Implement safe user handler entry/return, alternate stack if required, validated
    restored context and async-signal-safe runtime paths; never unwind across unauthorized frames
    or trust caller-provided privileged CPU state.
  • Implement signal-driven EINTR/restart, SIGCHLD/wait ordering, SIGPIPE,
    stop/continue and terminal job-control behavior required by the profile.
  • Implement per-process CPU/resource queries and required limits with real counters;
    elapsed wall time and child CPU time remain distinct.
  • Add fork/exec/wait VM matrices covering descriptor aliasing, close-on-exec,
    environment, cwd, TLS, signals, multi-thread fork, failures, concurrent children and
    termination while authority demand is pending.
  • Add cross-realm signal/control denial, stale-PID replay, descendant cleanup and
    repeated fork/exec exhaustion/recovery VMs; verify no residual caps.

For each implementation slice, retain actual formatting, strict Clippy, unit/doctest and warning-denied build results for all altered Rust repositories and valid configurations. Add relevant runtime VM coverage, monitor older unit/VM regressions in exact-head CI, and update canonical component documents and affected technical-manual/API material. Every authored code file must remain below 1,000 physical lines, with meaningful inline documentation and missing_docs enforcement in Rust crates.

Alternatives and tradeoffs

Copy-on-write may improve fork cost later but requires separate correctness and revocation evidence. Start with reviewed private copying and retain native process boundaries instead of pretending every fork is a spawn.

Tracking and rollout

Dependencies: posixd#1, posixd#2, kernel#1

Dependencies identify required contracts and closure gates; preparatory inventory/design can proceed in parallel under one owner per edited file. Link bounded implementation issues and their PRs here before claiming acceptance. Use feature/posix-compat, regular signed commits in the canonical contribution format, and WIP PRs linked to the exact coherent component graph. All cross-repository Cargo/catalog selections and CI helpers use full 40-character lowercase commit hashes, including transitive dependencies; do not substitute branch, tag or implicit HEAD selection.

Close criteria only with their own reviewed deliverables and validation evidence. Pending, skipped, cancelled, failed or predecessor-only results remain distinct. Keep main images unchanged until explicit promotion direction; technical completion does not authorize merges, release tags or publication.

## Problem and motivation Build processes and shell job control require real process snapshots, replacement, child status and signal delivery. Descriptive subshell state or spawn-only substitutes do not establish fork semantics or safe process control. ## Proposed behavior and scope Implement correctness-first fork, atomic publication/unwind, exec replacement, required spawn actions, wait/zombie retirement, signal state and handlers, groups/sessions and real resource counters. Validate concurrent children, threaded fork, descriptor inheritance, terminal control and exhaustion recovery. This issue records planned work; its unchecked criteria are not implementation proof. The normative basis is [Phase 6 and AC1–AC24](https://git.erikinkinen.fi/erix/docs/src/branch/main/phases/6.md). ## Authority, security and reliability Duplicate only authorized memory and descriptor rights; never copy private service receive authority. Bind signal/group/child operations to live generations inside the realm, validate restored CPU state, and retire descendants and pending exceptional grants on failure or termination. Apply the priority order: security, reliability, then performance. Keep suspected vulnerabilities in the repository’s restricted SECURITY.md reporting channel. ## Acceptance criteria - [ ] Specify fork's exact snapshot, return values, native generation, POSIX PID, shared open descriptions and allowed capability inheritance. A shell's descriptive subshell checkpoint is not a process fork. - [ ] Implement correctness-first private address-space copying unless a separately reviewed copy-on-write mechanism is justified; duplicate only selected memory/descriptor rights, never a service's private receive authority. - [ ] Implement atomic child publication and full unwind for allocation, mapping, transfer or startup failure; parent state remains usable and no half-started child or leaked authority remains. - [ ] Implement execve/exec-family replacement using exact executable identity, manifest, realm policy, argv/env, inherited descriptors and signal rules; success replaces the image, failure preserves the prior process. - [ ] Implement posix_spawn/file actions if required by imported tools; preserve the same inheritance/security semantics and test fork/exec equivalence where specified. Do not fake fork by always taking a spawn-only path. - [ ] Implement wait/waitpid and required wait options with exact child status, zombie retirement, multiple waiters, interruption and PID reuse safety. - [ ] Implement process groups/sessions and terminal foreground ownership entirely within delegated namespaces; numeric group IDs cannot grant control. - [ ] Implement sigaction, masks, pending delivery, default/ignore/caught dispositions, unblock ordering and supported signal sets with explicit state. - [ ] Implement safe user handler entry/return, alternate stack if required, validated restored context and async-signal-safe runtime paths; never unwind across unauthorized frames or trust caller-provided privileged CPU state. - [ ] Implement signal-driven EINTR/restart, SIGCHLD/wait ordering, SIGPIPE, stop/continue and terminal job-control behavior required by the profile. - [ ] Implement per-process CPU/resource queries and required limits with real counters; elapsed wall time and child CPU time remain distinct. - [ ] Add fork/exec/wait VM matrices covering descriptor aliasing, close-on-exec, environment, cwd, TLS, signals, multi-thread fork, failures, concurrent children and termination while authority demand is pending. - [ ] Add cross-realm signal/control denial, stale-PID replay, descendant cleanup and repeated fork/exec exhaustion/recovery VMs; verify no residual caps. For each implementation slice, retain actual formatting, strict Clippy, unit/doctest and warning-denied build results for all altered Rust repositories and valid configurations. Add relevant runtime VM coverage, monitor older unit/VM regressions in exact-head CI, and update canonical component documents and affected technical-manual/API material. Every authored code file must remain below 1,000 physical lines, with meaningful inline documentation and missing_docs enforcement in Rust crates. ## Alternatives and tradeoffs Copy-on-write may improve fork cost later but requires separate correctness and revocation evidence. Start with reviewed private copying and retain native process boundaries instead of pretending every fork is a spawn. ## Tracking and rollout Dependencies: [posixd#1](https://git.erikinkinen.fi/erix/posixd/issues/1), [posixd#2](https://git.erikinkinen.fi/erix/posixd/issues/2), [kernel#1](https://git.erikinkinen.fi/erix/kernel/issues/1) Dependencies identify required contracts and closure gates; preparatory inventory/design can proceed in parallel under one owner per edited file. Link bounded implementation issues and their PRs here before claiming acceptance. Use `feature/posix-compat`, regular signed commits in the canonical contribution format, and WIP PRs linked to the exact coherent component graph. All cross-repository Cargo/catalog selections and CI helpers use full 40-character lowercase commit hashes, including transitive dependencies; do not substitute branch, tag or implicit HEAD selection. Close criteria only with their own reviewed deliverables and validation evidence. Pending, skipped, cancelled, failed or predecessor-only results remain distinct. Keep main images unchanged until explicit promotion direction; technical completion does not authorize merges, release tags or publication.
erikinkinen changed title from [FEATURE] [P09] Implement real fork, exec, wait, signals and terminal process groups to [FEATURE] Implement real fork, exec, wait, signals and terminal process groups 2026-09-12 08:02:05 +02:00
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
feature/posix-compat
No results found.
Labels
Clear labels
  
bug
Something is not working

  
ci

   
docs

   
duplicate
This issue or pull request already exists

  
enhancement
New feature

  
help wanted
Need some help

  
invalid
Something is wrong

  
performance
Measured performance profiling, bottleneck analysis, and regression budgets.

  
phase-6
Phase 6: POSIX compatibility, full EriX self-hosting, and its required audits and validation.

  
question
More information is needed

  
refactor
Code cleanup, removal of obsolete paths, and structural improvements preserving behavior.

  
security

   
wontfix
This won't be fixed

No labels
bug
ci
docs
duplicate
enhancement
help wanted
invalid
performance
phase-6
question
refactor
security
wontfix
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
erix/posixd#3
No description provided.