ComputeManager copies these two templates into the staging tree it builds for each job, and they run inside a BYOC provider sandbox. They are not daemon startup scripts, and the direct SSH compatibility path never touches them.
| File | Responsibility |
|---|---|
run.sh.tmpl |
The job entry point, kept deliberately small: strict Bash mode, a change into the staged work directory, then the submitted command substituted at {{COMMAND}}. |
wrapper.sh.tmpl |
Supervises run.sh in a process group of its own. It keeps stdout and stderr apart, enforces both the job timeout and the sandbox deadline, reaps surviving descendants, writes the phase and deadline markers, and always tries to archive out/ plus the logs as out.tar.gz. |
./out/. An empty out/ is only a warning.OPENAI4S_JOB_TIMEOUT_S, OPENAI4S_HARVEST_MARGIN_S, OPENAI4S_TERM_GRACE_S, and either OPENAI4S_SANDBOX_REMAINING_S or OPENAI4S_SANDBOX_DEADLINE_EPOCH) are read and made read-only before .job_env is sourced, so a job cannot widen those limits through its own variables. The sandbox deadline exists only when the host supplies one: with no value the watchdog is simply not armed, which is the honest behaviour but not the same thing as "a deadline is always in force". The manager stamps the container's expiry when it creates the sandbox, so a later job reusing a warm container inherits the time already spent..phase records either done:<rc>:<wall> or harvest_failed:<rc>:<wall>. The order in which the deadline and job-timeout sentinels are written is part of the contract the host and provider use to classify how a job ended.{{COMMAND}} is executable job content on purpose, not shell-escaped data. What keeps it safe is the provider sandbox and the authority granted at submission.setsid, timeout, tar, process groups, and /proc/<pid>/stat. It is not a portable local shell wrapper..job_env is sourced inside a sandbox that is already authorized. The control variables are protected, but every other job environment value stays available to the workload.