Scheduler · XB Field Notes

The scheduler accounts for requests, not momentary utilization

Sun, 02 Apr 2028 00:00:00 +0000

Kubernetes scheduling answers whether a Pod can fit a node under the applicable resource requests and placement constraints. It does not simply look at a current CPU utilization chart and place work wherever the line is low. Requests provide accounting inputs for future demand; actual usage is a separate observation. Diagnose both before deciding that an idle-looking cluster has capacity for a particular Pod.

Read the admitted requests. API rejection, an accepted Pending Pod, and successful placement are different stages.

Account for the admitted specification

For ordinary application containers, the scheduler accounts for their requested resources when testing node fit. Initialization requirements, Pod overhead and supported Pod-level resource configuration can also affect the effective request. The final admitted Pod is the relevant input, including defaults and mutations, rather than just the source manifest that an operator remembers submitting.

Node allocatable is also different from the hardware’s total capacity. It represents the resource amount available to Pods under the node’s configuration. Other admitted workloads consume scheduling headroom through their requests even when their processes happen to be idle. A request does not mean that physical memory has already been allocated to the application or that CPU cores are exclusively assigned.

Limits constrain running workloads through the execution stack; they are not generally substituted for an explicitly smaller request in scheduler fit checks. A container can therefore have a CPU limit larger than one node’s CPU capacity and still schedule with a small request. That accepted limit does not manufacture additional processors or promise the process can reach the declared ceiling.

When it breaks

A Pending Pod may be blocked by insufficient requested resources, but also by taints, affinity, storage, topology or other constraints. Read the PodScheduled condition and scheduling events before changing resource values. Lowering requests cannot repair an incompatible node selector or unavailable volume, and blindly lowering an honest request can create runtime contention instead of a sound placement.

Defaulting makes omission easy to misread. When a limit is specified without a request, and no admission-time mechanism supplies another request, Kubernetes copies that resource’s limit into its request. Setting only a large limit can therefore produce a large scheduling demand. Inspect both maps on the stored object, including any LimitRange effects, before interpreting a failed placement.

The API also rejects a request greater than its corresponding limit. That is an admission failure, not a scheduler decision about cluster capacity. Keeping those failure stages separate helps explain why one manifest never creates a Pod while another produces an accepted but unscheduled Pod that can be inspected.

QoS is not an immunity promise. Under conventional per-container rules, Guaranteed requires CPU and memory requests and limits to be present and equal for every relevant container. Matching only memory is insufficient. Even a Guaranteed Pod can encounter resource failure; the class does not replace priority, capacity planning, application correctness or actual node-pressure analysis.

Check it quickly

The fixture and observations below are retained from the original article. This review did not rerun the Kubernetes integration; reported success is historical, not a new execution result.

Use a disposable Kubernetes cluster with at least one Ready, untainted worker, kubectl and python:3.11-slim-bookworm on its nodes. Save this as request-placement.py and run python3 request-placement.py KUBECONFIG_PATH CONTEXT with explicit test-cluster arguments. The account needs namespace creation and deletion permissions. The recorded server was Kubernetes 1.34.11, and the selected worker reported ten allocatable CPUs.

import json
import subprocess
import sys
import time
from uuid import uuid4

assert len(sys.argv) == 3, 'usage: python3 example.py DISPOSABLE_KUBECONFIG CONTEXT'
base = ['kubectl', '--kubeconfig', sys.argv[1], '--context', sys.argv[2], '--request-timeout=30s']
image = 'python:3.11-slim-bookworm'


def k(*args, payload=None, expected=0):
 result = subprocess.run(base + list(args), input=json.dumps(payload) if payload is not None else None,
 capture_output=True, text=True, timeout=150)
 if expected is not None:
 assert result.returncode == expected, result.stderr
 return result


def obj(namespace, kind, name=None, selector=None):
 args = ['get', kind, '-n', namespace, '-o', 'json']
 if name:
 args.append(name)
 if selector:
 args += ['-l', selector]
 return json.loads(k(*args).stdout)


def apply(namespace, data):
 return k('apply', '-n', namespace, '-f', '-', payload=data)


def wait_for(read, ready, seconds=120):
 until = time.monotonic() + seconds
 while time.monotonic() < until:
 value = read()
 if ready(value):
 return value
 time.sleep(0.5)
 raise AssertionError('expected Kubernetes condition did not arrive')


def pod_ready(pod):
 return any(c['type'] == 'Ready' and c['status'] == 'True'
 for c in pod.get('status', {}).get('conditions', []))


def spec(script='import time; time.sleep(600)'):
 return {'automountServiceAccountToken': False, 'terminationGracePeriodSeconds': 1,
 'containers': [{'name': 'app', 'image': image, 'imagePullPolicy': 'IfNotPresent',
 'command': ['python3', '-c', script],
 'resources': {'requests': {'cpu': '10m', 'memory': '24Mi'},
 'limits': {'cpu': '200m', 'memory': '96Mi'}}}]}

from decimal import Decimal, ROUND_CEILING

def cpu_quantity(value):
 return Decimal(value[:-1]) / 1000 if value.endswith('m') else Decimal(value)

namespace = 'notes-requests-' + uuid4().hex[:8]
k('create', 'namespace', namespace)
try:
 workers = [n for n in obj(namespace, 'nodes')['items'] if
 not n['spec'].get('unschedulable') and not n['spec'].get('taints')
 and any(c['type'] == 'Ready' and c['status'] == 'True' for c in n['status']['conditions'])]
 assert workers, 'a Ready worker without taints is required'
 worker = workers[0]
 allocatable = cpu_quantity(worker['status']['allocatable']['cpu'])
 too_large = str(int(allocatable.to_integral_value(rounding=ROUND_CEILING)) + 1)
 for name, request in [('burst', '10m'), ('oversized', too_large)]:
 podspec = spec()
 podspec['nodeSelector'] = {'kubernetes.io/hostname': worker['metadata']['labels']['kubernetes.io/hostname']}
 podspec['containers'][0]['resources'] = {
 'requests': {'cpu': request, 'memory': '24Mi'}, 'limits': {'cpu': too_large, 'memory': '96Mi'}}
 apply(namespace, {'apiVersion': 'v1', 'kind': 'Pod', 'metadata': {'name': name}, 'spec': podspec})
 burst = wait_for(lambda: obj(namespace, 'pod', 'burst'), pod_ready)
 assert burst['spec']['nodeName'] == worker['metadata']['name']
 def insufficient(p):
 return any(c['type'] == 'PodScheduled' and c['status'] == 'False'
 and c.get('reason') == 'Unschedulable' and 'Insufficient cpu' in c.get('message', '')
 for c in p.get('status', {}).get('conditions', []))
 pending = wait_for(lambda: obj(namespace, 'pod', 'oversized'), insufficient)
 assert pending['status']['phase'] == 'Pending' and not pending['spec'].get('nodeName')
 only_limit = spec()
 only_limit['containers'][0]['resources'] = {'limits': {'cpu': '200m', 'memory': '64Mi'}}
 apply(namespace, {'apiVersion': 'v1', 'kind': 'Pod', 'metadata': {'name': 'defaulted'}, 'spec': only_limit})
 defaulted = wait_for(lambda: obj(namespace, 'pod', 'defaulted'), pod_ready)
 resources = defaulted['spec']['containers'][0]['resources']
 assert resources['requests'] == resources['limits'] == {'cpu': '200m', 'memory': '64Mi'}
 assert defaulted['status']['qosClass'] == 'Guaranteed'
 invalid = spec()
 invalid['containers'][0]['resources'] = {'requests': {'cpu': '200m'}, 'limits': {'cpu': '100m'}}
 denied = k('create', '-n', namespace, '-f', '-', payload={
 'apiVersion': 'v1', 'kind': 'Pod', 'metadata': {'name': 'invalid'}, 'spec': invalid}, expected=None)
 assert denied.returncode != 0 and 'must be less than or equal to cpu limit' in denied.stderr
 print(json.dumps({'node_allocatable_cpu': str(allocatable), 'limit_cpu': too_large,
 'small_request_with_large_limit_scheduled': True,
 'larger_than_node_request_pending': True,
 'limit_only_defaulted_resources': resources,
 'defaulted_qos': defaulted['status']['qosClass'],
 'request_above_limit_rejected': True}))
finally:
 k('delete', 'namespace', namespace, '--wait=true', '--timeout=90s')

The script uses nodeSelector to target that worker while leaving the scheduler responsible for assignment. Both comparison Pods have an eleven-CPU limit. The first requests only ten millicpu and becomes Ready on the selected node. The second requests eleven CPUs, remains Pending without nodeName, and reports Unschedulable with Insufficient cpu. Neither Pod tries to consume eleven CPUs; their processes are idle.

A third Pod specifies only 200m CPU and 64Mi memory limits. The stored object contains identical requests, and its observed QoS class is Guaranteed. A fourth attempted Pod requests 200m while limiting CPU to 100m; the API rejects it. The original article reports that all assertions passed, and the namespace was removed.

This separates successful placement, scheduler rejection, defaulting and API validation with real objects. It does not test actual peak capacity, resource-manager exclusivity or every scheduling plugin. Size requests from workload evidence and review actual admitted demand alongside usage, instead of turning an idle chart or a familiar ratio into a placement guarantee.

Sources

Kubernetes: Resource Management, request-based placement, limits and admission defaulting, checked 2026-10-15.
Kubernetes: Pod Quality of Service Classes, Guaranteed requirements and the limits of QoS protection, checked 2026-10-15.

Kubernetes CronJobs need a history policy

Fri, 25 Feb 2028 00:00:00 +0000

A CronJob creates Jobs on a schedule, and each Job manages the Pods that perform the work. Finished objects can preserve useful status, but retention is bounded by several independent mechanisms. In particular, CronJobs already have default history limits. Omitting explicit history settings does not make ordinary completed runs accumulate forever.

Count and TTL do not guarantee minimum retention when the other permits earlier deletion. Cleanup is asynchronous, and active-job limits do not prove a business operation is safe to retry. The retained diagnostics were not rerun.

Separate history from log retention

The default CronJob history keeps up to three successful Jobs and one failed Job. The controller reconciles those categories independently. A zero limit requests no retained Jobs in that category, but cleanup is asynchronous rather than an exact completion-time deletion. Active Jobs are not completed-history entries and need separate attention.

Thirty days of hourly scheduling means 720 scheduled opportunities, not necessarily 720 retained Jobs or exactly 720 Pods. Missed schedules, concurrency policy, retries and parallelism change those relationships. A Job can own several Pods. State the assumptions before using run counts as storage or API-capacity estimates.

Keeping a Pod object also does not guarantee its logs remain available. Node failure, rotation, container cleanup and eviction affect log access. Export the operational evidence required by your retention policy to a suitable logging system. Kubernetes objects are useful investigation records, but they are not an archival guarantee.

Large retained histories still have costs: object storage, list sizes and investigation noise. A watch receives relevant changes rather than repeatedly emitting every unchanged object merely because it exists. Measure actual object counts and control-plane behavior instead of describing retained status as continuous activity.

Count and age are independent policies

The CronJob history limits constrain finished Job counts, not their minimum age. A busy schedule can replace the last failed record quickly, while a quiet schedule may keep it much longer. Choose counts from the inspection interval and failure frequency, rather than treating one retained failure as enough evidence for every workload.

TTL-after-finished is configured on the Job. For future CronJob-created Jobs, place ttlSecondsAfterFinished inside the Job template’s spec. The timer starts when a Job reaches Complete or Failed; expiry makes it eligible for cascading deletion. A zero TTL makes it eligible immediately, while an unset TTL supplies no age-based cleanup.

History cleanup and TTL can each remove a Job. Consequently, neither a large history count nor a long TTL guarantees minimum retention when the other mechanism permits earlier deletion. Finalizers and controller progress can delay physical removal. Editing a CronJob template affects future Jobs; it does not rewrite the policy of every existing Job.

Ownership determines cascading behavior

CronJob-created Jobs reference their owner, and Jobs reference their Pods through dependent ownership. Normal cascading deletion can remove that hierarchy. Explicit orphan deletion instead preserves dependents and removes the relevant ownership link; it does not intentionally leave an ordinary dangling reference for the collector to follow.

After orphaning Jobs, the former CronJob no longer trims their history. A configured TTL can still apply to each finished Job. Directly created Jobs also need an explicit retention decision. Check the actual deletion propagation policy and ownership rather than assuming every client uses identical defaults or that every orphan will soon disappear.

When it breaks

A Job that never reaches a terminal condition does not become eligible through finished-job TTL. History limits do not bound active runs either. An appropriate activeDeadlineSeconds can bound a Job’s runtime, while concurrencyPolicy controls overlapping schedules. These settings address different failure modes and do not prove the underlying operation is safe to retry.

Zero history can remove the failure record before anyone investigates it. Preserve required logs and result artifacts elsewhere before shortening retention. Conversely, a missing owner relationship or an absent TTL deserves investigation, not automatic deletion: another controller or retention requirement may deliberately own the cleanup decision.

Check it quickly

The following retained read-only diagnostics were not rerun in this review. Select a disposable test context and namespace. Compare the stored CronJob with the Jobs it actually owns, their completion conditions and creation times; namespace-wide totals below include unrelated workloads and active Jobs.

kubectl get cronjob hourly-rollup -o jsonpath='{.spec.successfulJobsHistoryLimit} {.spec.failedJobsHistoryLimit} {.spec.jobTemplate.spec.ttlSecondsAfterFinished}{"\n"}'
kubectl get jobs --sort-by=.metadata.creationTimestamp --no-headers | wc -l
kubectl get pods --field-selector=status.phase=Succeeded --no-headers | wc -l
kubectl get jobs -o jsonpath='{range .items[*]}{.metadata.name} ttl={.spec.ttlSecondsAfterFinished} owner={.metadata.ownerReferences[0].name}{"\n"}{end}'

The first line usually shows API-defaulted history values even when the manifest omitted them. Blank output is not proof of unlimited retention; check lookup errors and the complete object. The last line displays only the first owner reference. An absent TTL and owner mean these two particular mechanisms provide no demonstrated cleanup, not that deletion is impossible. Repeat inspection across completed runs, expecting bounded owned histories after reconciliation while active runs and unrelated objects are assessed separately.

Sources

Kubernetes Job, “Clean up finished jobs automatically” and the TTL mechanism for finished Jobs, checked 2026-10-15.
Kubernetes CronJob, default history limits and the job template, checked 2026-10-15.
Kubernetes garbage collection, owner references and cascading deletion, checked 2026-10-15.
Primary reference, TTL eligibility and finalizers, checked 2026-10-15.
Primary reference, log rotation and node-level retention, checked 2026-10-15.

Cron system and user tables have different contracts

Wed, 12 Jan 2028 00:00:00 +0000

User crontabs belong to one account; system tables can name an account per entry. Copying lines between formats without adjusting fields changes the command boundary. Identify the format before debugging the calendar expression.

In Debian user tables the command starts after five fields; system tables insert a username before it. Unescaped percent signs are handled before shell quoting and split off standard input. The figure is schematic; privileged examples were not executed.

The account column changes the parser boundary

User entries contain minute, hour, day of month, month, day of week, then command text; crontab installs them for the selected user. Debian’s /etc/crontab and /etc/cron.d files insert a username after those five fields. It is not an optional command annotation.

Month remains required. When day-of-month and day-of-week are both restricted, Debian/Vixie permits either day match, not month versus weekday. Check dialects before transferring expressions to schedulers with seconds fields or different day rules; similar spacing proves nothing.

System drop-ins require suitable ownership, permissions, filenames, and final newlines. Debian accepts root-owned files without group/other write permission and appropriate names, not arbitrary backup suffixes. Periodic directories such as /etc/cron.daily follow distribution scheduling, commonly through run-parts; scripts are not individually parsed as crontabs. Inspect the installed arrangement for timing.

When it breaks

Putting root after five fields in root’s user crontab asks the shell to execute a command named root; successful installation does not prove it exists. Omitting a system entry’s account instead puts command text in the username position. Check boundaries and effective identity, especially for protected data or writes.

Do not assume interactive aliases, shell startup files, or daemon-parent variables are available. Explicitly set required values, PATH, and interpreter. Nor should cron.d settings be assumed to inherit /etc/crontab’s environment. Test permissions and outputs as the execution account.

Before shell processing, unescaped percent signs delimit standard input; subsequent percents become newlines. Shell quoting cannot prevent this. Put complex commands in scripts and escape literal percents in entries. Check scheduling syntax, command execution, and application outcomes separately.

Check it quickly

Repair draft checked 2026-10-19: this revision was checked statically and with offline command/file-state doubles only. No daemon, account or task-table changes were executed. Technical and operational verification remain blocked. The version-specific outcomes below describe the original fixture.

A future run needs a separately authorized, freshly provisioned disposable Debian 12 lab with Python 3.11+, cron 3.0pl1-162, procps and passwd, an executable /tmp for the guarded shell script, no host mounts, no cron daemon or root table, no xbtime account or test drop-in, no enabled unrelated schedules in /etc/crontab, /etc/cron.d or any user’s spool (including periodic-directory dispatch), and no concurrent administration. Save as cron-tables.py; use python3 cron-tables.py --isolated-disposable-lab only after independently establishing those conditions. The flag and root identity do not prove isolation. This still modifies lab-wide account files and cron state; discard the whole lab afterward.

The temporary system account uses existing nogroup and the private work directory as its home, with no new home or private group and no lastlog initialization; its UID is discovered, not assumed to be 1000. Account creation, lookup, table installation and daemon startup are protected from the first attempted mutation. Both test tables disable mail with MAILTO. The exact pinned absence diagnostic is distinguished from permission or command failure. Workers publish JSON by same-directory replacement; the deliberately invalid entry still starts with root after its five fields. Only that entry selects a small SHELL wrapper that checks the permit under the shared lock, preserves the lock descriptor across exec and passes the unchanged command to /bin/sh. Its diagnostic is published by rename. A positive run permit and shared lifetime lock bound admitted worker cleanup. Every cleanup action is attempted independently, with bounded daemon and worker waits; errors preserve the original failure and skip private-file deletion; a failed deletion can leave only partial files. Revoking the permit prevents late workers from treating a deleted stop file as permission. The barrier does not prove every cron wrapper exited, so lab disposal remains required.

from pathlib import Path
from tempfile import mkdtemp
import fcntl
import json
import os
import pwd
import shutil
import subprocess
import sys
import time


def command(arguments, **options):
 return subprocess.run(arguments, capture_output=True, text=True, timeout=5,
 env={**os.environ, 'LC_ALL': 'C'}, **options)


def table_absent(result):
 # Debian cron 3.0pl1-162: other listing failures must abort.
 return (result.returncode == 1 and result.stdout == ''
 and result.stderr == 'no crontab for root\n')


def remove_table():
 current = command(['crontab', '-l'])
 if table_absent(current):
 return
 current.check_returncode()
 command(['crontab', '-r']).check_returncode()
 if not table_absent(command(['crontab', '-l'])):
 raise RuntimeError('could not verify table removal')


def attempt(errors, name, operation):
 try:
 operation()
 except Exception as error:
 errors.append(f'{name}: {error!r}')


def stop_daemon(daemon, errors):
 if daemon is None:
 return
 attempt(errors, 'terminate cron', daemon.terminate)
 try:
 daemon.wait(timeout=5)
 except subprocess.TimeoutExpired:
 attempt(errors, 'kill owned cron', daemon.kill)
 attempt(errors, 'reap cron', lambda: daemon.wait(timeout=5))
 except Exception as error:
 errors.append(f'wait cron: {error!r}')


def remove_account(username):
 try:
 pwd.getpwnam(username)
 except KeyError:
 return
 command(['userdel', username]).check_returncode()
 try:
 pwd.getpwnam(username)
 except KeyError:
 return
 raise RuntimeError('account removal not verified')


def wait_workers(root):
 with (root / 'lifetime.lock').open() as gate:
 deadline = time.monotonic() + 5
 while True:
 try:
 fcntl.flock(gate, fcntl.LOCK_EX | fcntl.LOCK_NB)
 return
 except BlockingIOError:
 if time.monotonic() >= deadline:
 raise TimeoutError('workers did not release lifetime lock')
 time.sleep(0.1)


worker_source = r'''from pathlib import Path
import fcntl,json,os,sys
root=Path(__file__).parent
mode=sys.argv[1]
with (root/'lifetime.lock').open() as gate:
 fcntl.flock(gate,fcntl.LOCK_SH)
 if not (root/'run-permit').exists(): raise SystemExit(0)
 data={'uid':os.getuid(),'table':os.environ.get('LAB_TABLE'),
 'path':os.environ.get('PATH'),'shell':os.environ.get('SHELL'),
 'parent_only':os.environ.get('PARENT_ONLY')}
 if mode=='percent': data['stdin']=sys.stdin.read()
 destination=root/(mode+'.json')
 temporary=root/f'{mode}-{os.getpid()}.tmp'
 temporary.write_text(json.dumps(data))
 temporary.replace(destination)
'''


shell_source = r'''#!/usr/bin/python3
from pathlib import Path
import fcntl,os,sys
root=Path(__file__).parent
with (root/'lifetime.lock').open() as gate:
 fcntl.flock(gate,fcntl.LOCK_SH)
 if not (root/'run-permit').exists(): raise SystemExit(0)
 os.set_inheritable(gate.fileno(),True)
 os.execv('/bin/sh',['/bin/sh',*sys.argv[1:]])
'''


def main():
 if sys.argv[1:] != ['--isolated-disposable-lab']:
 raise SystemExit('requires a separately verified disposable Debian 12 lab')
 if os.geteuid() != 0:
 raise RuntimeError('root is required, but does not prove isolation')
 probe = command(['pgrep', '-x', 'cron'])
 if probe.returncode != 1 or probe.stdout or probe.stderr:
 raise RuntimeError(f'cron absence not established: {probe!r}')
 if not table_absent(command(['crontab', '-l'])):
 raise RuntimeError('expected absent root table; existing table or listing error')
 if shutil.which('root', path='/usr/bin:/bin') is not None:
 raise RuntimeError('the deliberately invalid command exists')
 username = 'xbtime'
 try:
 pwd.getpwnam(username)
 except KeyError:
 pass
 else:
 raise RuntimeError('test account already exists')
 system_table = Path('/etc/cron.d/xbcatm_time_test')
 if system_table.exists() or system_table.is_symlink():
 raise RuntimeError('system test table already exists')
 root = Path(mkdtemp(prefix='cron-tables-', dir='/tmp'))
 daemon = None
 account_attempted = account_created = table_attempted = system_owned = False
 try:
 (root / 'lifetime.lock').touch(mode=0o644)
 (root / 'run-permit').touch()
 account_attempted = True
 command(['useradd', '--system', '--no-create-home', '--no-user-group',
 '--gid', 'nogroup', '--home-dir', str(root), '--no-log-init', '--shell', '/bin/sh', username]).check_returncode()
 account_created = True
 account = pwd.getpwnam(username)
 os.chown(root, account.pw_uid, account.pw_gid)
 worker = root / 'worker.py'
 worker.write_text(worker_source)
 # The account must read both files even under a restrictive parent umask.
 worker.chmod(0o644)
 guarded_shell = root / 'guarded-shell'
 guarded_shell.write_text(shell_source)
 guarded_shell.chmod(0o755)
 (root / 'lifetime.lock').chmod(0o644)
 user_table = ('SHELL=/bin/sh\nPATH=/usr/bin:/bin\nLC_ALL=C\nMAILTO=""\nLAB_TABLE=user\n'
 f'* * * * * /usr/bin/python3 {worker} user\n'
 f'* * * * * /usr/bin/python3 {worker} percent%first%second\n'
 f'SHELL={guarded_shell}\n'
 f'* * * * * root /usr/bin/id >{root}/wrong-column.tmp 2>&1; '
 f'/bin/mv {root}/wrong-column.tmp {root}/wrong-column.err\n')
 table_attempted = True
 command(['crontab', '-'], input=user_table).check_returncode()
 invalid = command(['crontab', '-'], input='* * * * * /bin/true')
 assert invalid.returncode != 0
 listed = command(['crontab', '-l'])
 listed.check_returncode()
 assert listed.stdout == user_table
 with system_table.open('x') as handle:
 system_owned = True
 handle.write('SHELL=/bin/sh\nPATH=/usr/bin:/bin\nLC_ALL=C\nMAILTO=""\nLAB_TABLE=system\n'
 f'* * * * * {username} /usr/bin/python3 {worker} system\n')
 system_table.chmod(0o644)
 daemon = subprocess.Popen(['cron', '-f'], env={**os.environ, 'PARENT_ONLY': 'parent-demo'},
 stdout=subprocess.DEVNULL, stderr=subprocess.DEVNULL)
 deadline = time.monotonic() + 75
 names = ['user.json', 'system.json', 'percent.json', 'wrong-column.err']
 while time.monotonic() < deadline:
 if daemon.poll() is not None:
 raise RuntimeError('cron exited')
 if all((root / name).exists() for name in names):
 break
 time.sleep(0.2)
 else:
 raise AssertionError('scheduled table outputs were not produced')
 user = json.loads((root / 'user.json').read_text())
 system = json.loads((root / 'system.json').read_text())
 percent = json.loads((root / 'percent.json').read_text())
 wrong = (root / 'wrong-column.err').read_text()
 assert user['uid'] == 0 and user['table'] == 'user'
 assert system['uid'] == account.pw_uid and system['table'] == 'system'
 assert all(value['parent_only'] is None for value in (user, system))
 assert all(value['path'] == '/usr/bin:/bin' for value in (user, system))
 assert all(value['shell'] == '/bin/sh' for value in (user, system))
 assert percent['stdin'] == 'first\nsecond\n'
 assert 'root: not found' in wrong
 print(json.dumps({'user_table': user, 'system_table': system,
 'missing_final_newline_rejected': invalid.returncode,
 'previous_table_preserved': True, 'percent_stdin': percent['stdin'],
 'username_in_user_table_fails': wrong.strip()}), flush=True)
 finally:
 original = sys.exc_info()[1]
 errors = []
 attempt(errors, 'revoke run permit', lambda: (root / 'run-permit').unlink(missing_ok=True))
 if system_owned:
 attempt(errors, 'remove system table', lambda: system_table.unlink(missing_ok=True))
 if table_attempted:
 attempt(errors, 'remove root table', remove_table)
 stop_daemon(daemon, errors)
 attempt(errors, 'wait for workers', lambda: wait_workers(root))
 if account_attempted:
 attempt(errors, 'remove account', lambda: remove_account(username))
 if not account_created:
 errors.append('account creation failed partway; database state needs lab disposal')
 if not errors:
 attempt(errors, 'remove private files', lambda: shutil.rmtree(root))
 if errors:
 message = 'cleanup incomplete; discard lab: ' + '; '.join(errors)
 if original is not None:
 original.add_note(message)
 else:
 raise RuntimeError(message)


if __name__ == '__main__':
 main()

Historically, the user job ran as UID zero and the new system-table account as UID 1000; this revision discovers its system account’s UID instead. Both receive separate LAB_TABLE values and explicit PATH, without the daemon parent’s PARENT_ONLY. Percent parsing supplies first\nsecond\n on stdin. The misplaced username produces root: not found despite successful installation.

A replacement missing its final newline is rejected with exit one, preserving the previous table. The original fixture reported passing assertions on cron 3.0pl1-162; this revision has no real daemon result. Separate probes found malformed minute text accepted even in dry-run mode, so zero exit does not guarantee valid fields. Account, environment, parsing, and installation observations leave mail delivery, daylight-saving handling, and business success untested; verify these separately.

Sources

Debian 12: crontab(5), user/system table syntax, environment and percent handling, checked 2026-09-13.
Debian 12: cron(8), system drop-ins, ownership and execution environment, checked 2026-09-13.
Debian 12: crontab(1), installation, dry-run behavior and newline requirements, checked 2026-09-13.
Python 3.11 subprocess, timeout and child cleanup semantics, checked 2026-10-19.
Debian cron 3.0pl1-162 crontab.c, distinguish absent-table diagnostics from other failures, checked 2026-10-19.
Python 3.11 os.replace, atomic same-filesystem publication, checked 2026-10-19.
Debian cron 3.0pl1-162 do_command.c, configured shell receives -c and the command, checked 2026-10-19.
Python 3.11 os, descriptor inheritance and exec, checked 2026-10-19.
Linux flock(2), lock lifetime across exec, checked 2026-10-19.
Debian 12 useradd(8), system-account, group, home and log-initialization options, checked 2026-10-19.