Process · XB Field Notes

Socket activation passes a listener to a compatible service

Mon, 08 Nov 2027 00:00:00 +0000

Socket activation lets systemd open a listening endpoint before the application process starts. Activity on that endpoint can then trigger a compatible service, which receives descriptors for sockets the manager already owns. The useful boundary is listener ownership versus application lifetime. An open endpoint is not yet proof that the application has initialized, accepted a request, or produced a correct response.

When it breaks

The application must understand the activation protocol. A daemon that unconditionally binds the same endpoint again can fail because the manager already occupies it. Activation moves binding responsibility into the socket unit; it does not eliminate address conflicts, missing interfaces, filesystem permission errors, or other reasons that initial bind can fail.

With Accept=no, the service receives the listening socket and handles acceptance itself. Accept=yes instead supports a per-connection service-instance model for suitable stream sockets. These are different application contracts. Neither mode implies that an arbitrary daemon will automatically become idle, exit after work, or restart only when doing so is safe.

Queued connections also have limits. Clients can establish transport state before application startup finishes, then time out waiting for a response. Socket activation does not make database dependencies ready or create an unlimited request queue. Keep explicit service dependencies, readiness behavior, and client timeouts appropriate to the real workload.

Check it quickly

Run this Python script as an administrator in a disposable Linux system whose PID 1 is systemd. The recorded environment was Debian 12 with systemd 252.39. It creates a unique socket/service pair using a Unix stream socket in a temporary directory. No public TCP port is exposed. The worker intentionally serves one newline-terminated message and exits:

from pathlib import Path
from tempfile import TemporaryDirectory
import json,socket,subprocess,time,uuid

name='xbcatm-socket-'+uuid.uuid4().hex[:8];service=name+'.service';unit=name+'.socket'
paths={n:Path('/run/systemd/system')/n for n in (service,unit)}
assert all(not p.exists() for p in paths.values())
def run(*args):
 result=subprocess.run(args,capture_output=True,text=True,timeout=10)
 assert result.returncode==0,(args,result.stderr)
 return result.stdout.strip()
def value(key):return run('systemctl','show',service,'-p',key,'--value')
def wait_inactive():
 deadline=time.monotonic()+5
 while value('ActiveState')!='inactive':
 assert time.monotonic()<deadline,'service did not exit';time.sleep(0.02)
with TemporaryDirectory(prefix=name+'-',dir='/run') as directory:
 root=Path(directory);endpoint=root/'listener.sock';worker=root/'worker.py'
 worker.write_text(r'''from pathlib import Path
import errno,json,os,socket
root=Path(__file__).parent
assert int(os.environ['LISTEN_PID'])==os.getpid()
assert int(os.environ['LISTEN_FDS'])==1
with socket.socket(fileno=3) as listener:
 assert listener.getsockopt(socket.SOL_SOCKET,socket.SO_ACCEPTCONN)==1
 with socket.socket(socket.AF_UNIX,socket.SOCK_STREAM) as duplicate:
 try:duplicate.bind(str(root/'listener.sock'))
 except OSError as error:assert error.errno==errno.EADDRINUSE
 else:raise AssertionError('unexpected duplicate bind success')
 connection,_=listener.accept()
 with connection,connection.makefile('rb') as incoming:
 message=incoming.readline(256);assert message.endswith(b'\n')
 connection.sendall(b'ack '+message)
 (root/(str(os.getpid())+'.json')).write_text(json.dumps({'pid':os.getpid(),'fd':3,'message':message.decode().strip()}))
''')
 paths[unit].write_text(f'[Socket]\nListenStream={endpoint}\nAccept=no\nSocketMode=0600\nRemoveOnStop=yes\n')
 paths[service].write_text(f'[Service]\nType=exec\nExecStart=/usr/bin/python3 {worker}\n')
 try:
 run('systemd-analyze','verify',*[str(p) for p in paths.values()]);run('systemctl','daemon-reload')
 run('systemctl','start',unit)
 assert endpoint.is_socket() and value('ActiveState')=='inactive' and value('MainPID')=='0'
 print('socket listening while service has no process')
 for message in ('first','second'):
 with socket.socket(socket.AF_UNIX,socket.SOCK_STREAM) as client:
 client.settimeout(5);client.connect(str(endpoint));client.sendall((message+'\n').encode())
 with client.makefile('rb') as response:assert response.readline()==('ack '+message+'\n').encode()
 wait_inactive();assert endpoint.is_socket() and value('Result')=='success'
 records=[json.loads(p.read_text()) for p in root.glob('*.json')]
 assert len(records)==2 and len({row['pid'] for row in records})==2
 assert {row['message'] for row in records}=={'first','second'}
 assert all(row['fd']==3 for row in records)
 print('two requests: two deliberate one-request workers; each uses inherited listening fd 3')
 print('rebinding the occupied socket fails; manager retains listener between workers')
 run('systemctl','stop',unit);assert not endpoint.exists()
 print('stopping socket removes its endpoint with RemoveOnStop=yes')
 finally:
 run('systemctl','stop',unit,service)
 for name,path in paths.items():
 if run('systemctl','show',name,'-p','ActiveState','--value')=='failed':run('systemctl','reset-failed',name)
 path.unlink()
 run('systemctl','daemon-reload')

After starting only the socket unit, the endpoint exists while the corresponding service is inactive and has no main PID. A first client connection then causes the worker to execute. The client sends a complete framed message and checks an application reply, rather than treating a successful connect call as proof of usable service.

The worker verifies that LISTEN_PID names its own process and LISTEN_FDS reports one inherited descriptor. It wraps descriptor three and checks that it is already listening. The numbering and environment checks match the native activation contract. A production program handling multiple descriptors should also identify and validate the sockets it actually expects.

Attempting another bind to the same Unix socket path produces EADDRINUSE. The worker continues using the inherited listener and returns the expected reply. This controlled failure demonstrates why an application cannot simply retain its ordinary bind path while assuming activation will somehow avoid the conflict.

After the worker exits successfully, the manager still holds the listening endpoint. A second connection launches another worker, which handles the second message and exits. The recorded PIDs are different and both invocations used descriptor three. Two processes appear because this specific worker deliberately exits after one request; Accept=no did not itself require one process per connection.

Stopping the socket unit removes the endpoint because the fixture explicitly sets RemoveOnStop=yes. The script then stops any remaining test units and removes their runtime definitions and temporary files. This cleanup behavior is configured and observed, not a universal promise that every socket path disappears whenever any associated daemon exits.

Design the handoff and shutdown together

For a long-running daemon, accept and serve the inherited sockets using its documented integration, and let its normal shutdown behavior decide when descriptors close. For a daemon intended to leave when idle, verify the idle-exit logic and what happens to in-flight requests. systemd cannot infer when an application’s work is safely complete.

Stopping future activation and terminating current work are separate operational decisions. Inspect both socket and service units during maintenance. A service may be started explicitly through another dependency or by an operator, and a still-active listener may trigger it again. Test the deployed unit relationships rather than assuming that stopping one visible process permanently disables the endpoint.

Set appropriate endpoint permissions and service identity. Passing an already-open descriptor allows listener setup and application privileges to differ, but it does not make the service a sandbox. Verify real request handling, restart behavior, queued-client outcomes, and failure diagnostics. The practical advantage is a deliberate, testable handoff between listener and process, not automatic readiness or zero resource cost.

Sources

systemd 252 systemd.socket, listener ownership, Accept modes, activation, and endpoint removal, checked 2026-09-12.
systemd 252 sd_listen_fds, inherited descriptor numbering, count, and process-identity checks, checked 2026-09-12.
systemd 252 systemd.service, service startup types and process lifecycle, checked 2026-09-12.

Fork creates a process; exec replaces its program

Tue, 12 Oct 2027 00:00:00 +0000

Fork followed by exec is one common Unix process-launch model. fork creates a child process, while a successful execve replaces the calling process’s program image. They solve different problems and have different inheritance rules. Understanding the distinction matters when arranging input, output, environment, and lifecycle management for a command started by another program.

When it breaks

Fork does not make all subsequent state independent. Ordinary private memory diverges between parent and child, commonly through copy-on-write, but shared mappings remain shared. Inherited descriptors also refer to the same open file descriptions as their parent counterparts, so ordinary file offsets can move in both processes when either one reads. Copying the descriptor table does not independently reopen each file.

Exec does not simply preserve every launch setting. Descriptors marked close-on-exec close during successful execution, while other eligible descriptors survive. execve receives an explicit environment array instead of automatically reproducing the caller’s current environment. Caught signal dispositions reset and old memory mappings disappear, even though process identity and several other attributes continue.

Forking a multithreaded process needs particular care. The child contains only the calling thread but can inherit locks whose owning threads are absent. Arbitrary library work in the gap can deadlock. The allowed pre-exec operations are therefore constrained; a convenient single-threaded demonstration must not become an unrestricted recipe for manipulating a live threaded server after fork.

Check it quickly

Save this as forkexec.py and run python3 forkexec.py in a disposable Linux environment. The recorded run used Linux 6.12.76 and Python 3.11.2. This fixture is deliberately single-threaded. It uses one private Python value, one explicitly shared anonymous mapping, a temporary data file, and a pipe for a small result:

from pathlib import Path
from tempfile import TemporaryDirectory
import errno,json,mmap,os,sys

program=r'''
import errno,json,os,sys
original_pid,kept,dropped,report=map(int,sys.argv[1:])
assert os.getpid()==original_pid
try:os.fstat(dropped)
except OSError as error:assert error.errno==errno.EBADF
else:raise AssertionError('close-on-exec descriptor survived')
assert os.read(kept,2)==b'ef'
assert os.environ['XB_FORK_VALUE']=='child-value'
os.write(report,json.dumps({'pid_unchanged':True,'kept_descriptor':'ef','close_on_exec':'closed','explicit_environment':'child-value'}).encode())
'''
with TemporaryDirectory(prefix='xbcatm-fork-') as directory:
 data=Path(directory)/'data';data.write_bytes(b'abcdef')
 descriptor=os.open(data,os.O_RDONLY);dropped=os.dup(descriptor)
 read_end,write_end=os.pipe();os.set_inheritable(descriptor,True);os.set_inheritable(write_end,True)
 assert not os.get_inheritable(dropped)
 private=['parent'];shared=mmap.mmap(-1,8,flags=mmap.MAP_SHARED);shared[:]=b'parent!!'
 assert os.read(descriptor,2)==b'ab'
 sys.stdout.flush();pid=os.fork()
 if pid==0:
 try:
 os.close(read_end);private[0]='child';shared[:]=b'child!!!'
 assert os.read(descriptor,2)==b'cd'
 try:os.execve(str(Path(directory)/'missing-program'),['missing-program'],{})
 except FileNotFoundError:pass
 else:raise AssertionError('missing exec unexpectedly succeeded')
 os.execve(sys.executable,[sys.executable,'-c',program,str(os.getpid()),str(descriptor),str(dropped),str(write_end)],{'XB_FORK_VALUE':'child-value'})
 except BaseException as error:
 os.write(write_end,('ERROR '+repr(error)).encode());os._exit(1)
 os.close(write_end)
 try:
 waited,status=os.waitpid(pid,0);report=os.read(read_end,4096)
 assert waited==pid and os.WIFEXITED(status) and os.WEXITSTATUS(status)==0,report
 result=json.loads(report);assert result['pid_unchanged']
 assert private==['parent'] and shared[:]==b'child!!!'
 assert os.lseek(descriptor,0,os.SEEK_CUR)==6
 print('fork: private Python state diverges, MAP_SHARED changes and open-description offsets remain shared')
 print('missing exec returns to the child; successful exec keeps its PID, honors close-on-exec, and receives an explicit environment')
 print('parent reaped a successful exit with waitpid and retained its original private value')
 finally:
 shared.close()
 for fd in [descriptor,dropped,read_end]:os.close(fd)

Before fork, the parent reads ab from abcdef. The child changes its private Python list and the shared mapping, then reads cd through the inherited descriptor. After the child finishes, the parent’s list still contains its original value, but the shared mapping contains the child’s bytes. Both results are required to describe memory inheritance accurately.

The child first tries to execute a nonexistent file. That ordinary missing-path failure raises FileNotFoundError, and the child continues running its existing program. It then successfully executes Python again with a supplied program and an explicit environment. The example verifies this recoverable failure case; it does not generalize every rare execution failure into the same recovery behavior.

The replacement program compares its PID with the child’s PID passed before exec and finds them equal. Exec has replaced code within the child, not created a third process. The explicitly provided environment contains the fixture value, which the replacement reads directly; it does not depend on a login shell or an implicit profile-loading step.

The retained data descriptor reads ef, showing that the original parent’s read, the child’s read, and the replacement program’s read advanced one shared open-description offset. Meanwhile, the descriptor left non-inheritable fails inspection with EBADF in the replacement. The fixture deliberately marks only the descriptors needed across exec as inheritable.

The parent uses waitpid to collect the child’s status and confirms a normal zero exit. It then observes offset six through its own descriptor and closes its resources. Waiting obtains lifecycle information and reaps the exited child; the child’s numerical PID alone is not a substitute for collecting completion or verifying which launch succeeded.

Make launch ownership explicit

Define which descriptors a child needs, close unused pipe ends, and choose environment values deliberately. An extra inherited pipe writer can prevent a reader from seeing EOF even after the intended producer exits. Descriptor lifetime is therefore part of the communication protocol, not merely a cleanup detail after program startup.

Prefer the runtime’s supported subprocess or spawn interface when it expresses the needed setup. Such interfaces can use mechanisms other than a literal fork/exec pair. Their documented descriptor and environment behavior is the relevant application contract; assuming every launcher follows an identical internal sequence can produce incorrect portability and safety conclusions.

Distinguish launch failure, program failure, and failure to observe completion. A successful exec never returns to the previous program, whereas the replacement can later exit unsuccessfully. Record the actual child status and preserve enough context to identify the attempted command, without logging confidential environment values. That gives launch supervision a verifiable outcome rather than an inferred success.

Sources

fork(2), private memory, shared mappings, inherited descriptions, and thread restrictions, checked 2026-09-12.
execve(2), image replacement, explicit environment, preserved PID, and close-on-exec, checked 2026-09-12.
waitpid(2), collecting child status and reaping an exited child, checked 2026-09-12.

Umask filters new permissions, with a default ACL exception

Sat, 09 Oct 2027 00:00:00 +0000

A process’s umask removes permission bits when creating files and directories under the ordinary mode-based creation rule. The application first supplies a requested mode; the mask restricts that request. It is neither a complete access policy nor an instruction to rewrite existing files. A directory’s default access control list changes the creation calculation, so inspecting only the process mask can give an incomplete prediction.

When it breaks

Without a default ACL, the ordinary permission result is the requested mode bitwise AND the complement of umask. For requested 0666 and mask 0022, that gives 0644. This is not arithmetic subtraction. A request for 0600 remains 0600 under the same mask, and a request that omits execute permission does not acquire it because the mask is permissive.

A restrictive umask does not repair an existing world-writable file. Opening and truncating that file changes content while preserving its existing mode. A later chmod can also widen permissions regardless of the current mask. Treating umask as a permanent upper bound on permissions therefore leaves both existing-file and subsequent-permission-change cases unaccounted for.

When the parent directory supplies a default ACL, Linux derives the new access ACL from that default and restricts it by the application’s requested mode; the process umask is not applied in the ordinary way. A shared directory can consequently produce group-accessible files even when the creator’s mask is 0077. The inherited ACL must be part of the diagnosis.

Check it quickly

Save this as mask.py and run python3 mask.py on Linux with Python 3 and setfacl installed. The temporary-file directory must support default ACLs. The recorded run used Python 3.11.2, acl 2.3.1, and a separate ext4 volume selected through TMPDIR. The initial tmpfs environment rejected default ACLs, so the complete experiment was rerun on ext4:

from pathlib import Path
from tempfile import TemporaryDirectory
import os,stat,subprocess

def create(path,requested):
 fd=os.open(path,os.O_WRONLY|os.O_CREAT|os.O_EXCL,requested);os.close(fd)
def mode(path):return stat.S_IMODE(path.stat().st_mode)
previous=os.umask(0o022)
try:
 with TemporaryDirectory(prefix='xbcatm-umask-') as directory:
 root=Path(directory)
 data=root/'data';create(data,0o666);assert mode(data)==0o644
 executable=root/'executable';create(executable,0o777);assert mode(executable)==0o755
 private=root/'private';create(private,0o600);assert mode(private)==0o600
 folder=root/'folder';folder.mkdir(mode=0o777);assert mode(folder)==0o755
 assert 0o600&~0o022==0o600 and 0o600-0o022!=0o600
 print('without default ACL: requested mode AND NOT umask; 0666 becomes 0644, 0777 becomes 0755')
 os.umask(0o077)
 strict=root/'strict';create(strict,0o666);assert mode(strict)==0o600
 existing=root/'existing';create(existing,0o666);existing.chmod(0o666)
 fd=os.open(existing,os.O_WRONLY|os.O_TRUNC);os.close(fd)
 assert mode(existing)==0o666
 print('restrictive mask leaves an existing 0666 file unchanged; chmod can widen permissions later')
 acl_folder=root/'acl';acl_folder.mkdir()
 subprocess.run(['setfacl','-d','-m','u::rwx,g::rwx,o::---',str(acl_folder)],check=True)
 inherited=acl_folder/'inherited';create(inherited,0o666)
 restricted=acl_folder/'restricted';create(restricted,0o600)
 assert mode(inherited)==0o660 and mode(restricted)==0o600
 print('with default ACL and umask 0077: request 0666 yields 0660; request 0600 still yields 0600')
 status=dict(line.split(':',1) for line in Path('/proc/self/status').read_text().splitlines() if ':' in line)
 assert int(status['Umask'].strip(),8)==0o077
 print('/proc/self/status observes this process mask without temporarily changing it')
finally:os.umask(previous)

With mask 0022 and no inherited default ACL, requesting 0666 produces a 0644 file. Requesting 0777 produces 0755 for both a regular file and a directory, while requesting 0600 still produces 0600. The fixture also checks that arithmetic subtraction would give a different result for the restrictive request, exposing that common calculation error.

After switching to mask 0077, a newly created file requested as 0666 becomes 0600. Another file is explicitly changed to 0666, then opened with truncation but without creation. Its mode stays 0666. This comparison distinguishes initial creation from later operations on an existing inode, rather than assuming every open reapplies creation policy.

Next, the fixture installs a default ACL granting the owning user and group full permissions and granting others none. Under the still-active 0077 mask, a new file requested as 0666 receives mode 0660. The inherited ACL preserves group read/write permissions despite the restrictive mask, but the application’s request excludes execute permission.

A neighboring file requested as 0600 remains 0600 under that same default ACL. The default does not invent permissions absent from the requested mode. These two requests establish both the default-ACL exception to ordinary masking and the continued role of the application’s explicit creation request.

The script reads Umask from /proc/self/status and confirms that the process mask is still 0077. It restores the original mask in finally and removes the temporary tree. If the selected filesystem cannot install the ACL, the command fails; skipping that step would leave the central exception untested.

Apply creation policy at the right layer

Umask is inherited through normal process creation and preserved across execution of another program. Set it in the actual launch path for a service or command. An unrelated terminal’s mask does not retroactively change the state of an already running process, and shell startup files matter only when the launch path reads them.

Because umask is process-wide for threads sharing the relevant filesystem state, temporarily changing it to discover its previous value can interfere with concurrent file creation. On Linux, reading the proc status field avoids that mutation. Applications needing a specific private file should request suitably restrictive permissions and verify their actual storage context.

Inspect parent-directory access, ownership, ACLs, and the resulting file permissions together. A 0660 file inside an inaccessible parent is not automatically reachable by its group, and mode bits alone do not describe all named ACL entries. The experiment proves creation results; end-to-end access requires testing the intended identity through the complete path.

Sources

umask(2), creation masks, inheritance, default ACL interaction, and proc inspection, checked 2026-09-12.
acl(5), default ACL inheritance and requested-mode permission restrictions, checked 2026-09-12.
open(2), creation modes and opening or truncating an existing file, checked 2026-09-12.

Shell pipes stream between processes

Tue, 28 Sep 2027 00:00:00 +0000

A shell pipeline connects one command’s standard output to the next command’s standard input. The commands can run concurrently, so the producer need not finish before the consumer starts. This supports incremental processing, but the pipe itself does not guarantee that either program processes data incrementally. Buffering, early termination, and the status of each stage determine whether the complete operation does what you intended.

A byte stream with finite capacity

A pipe transports bytes rather than records. A reader is not promised one read per line or one read per producer write. Programs must implement any framing they need. Standard error normally remains separate, which is why an upstream diagnostic can appear on the terminal without entering the downstream filter. Decide explicitly whether a consumer should receive diagnostics as data.

The kernel provides finite buffering. A blocking writer waits when the pipe fills, and a reader waits when the pipe is empty while writers remain open. This backpressure limits how far a producer can advance through that particular pipe. Capacity depends on the operating system and configuration; it is not universally sixty-four kibibytes. Applications can still accumulate arbitrarily large internal data structures, so a pipeline alone does not bound total memory.

User-space buffering adds another delay. A program that flushes every line to a terminal may buffer larger chunks when stdout is a pipe. An apparently idle consumer may therefore be waiting for data still buffered in the producer. Check the producer’s documented streaming and flush controls before changing kernel limits or adding arbitrary sleeps. Some transformations, such as a complete sort, inherently need more input before producing useful output.

When it breaks

A reader sees end-of-file only after every descriptor referring to the write end is closed. A child that inherited an unused write descriptor can keep a consumer waiting even after the apparent producer exited. In the other direction, writing after all read ends are closed generates SIGPIPE, or yields an EPIPE error when the signal is ignored. A consumer that deliberately stops early can therefore cause an otherwise healthy producer to terminate unsuccessfully.

By default, Bash returns the last stage’s status. An upstream failure followed by a successful cat can look successful overall. With pipefail, the aggregate result is the rightmost nonzero stage status, not the first failure in time or the leftmost failing command. The PIPESTATUS array retains individual stage results briefly. Capture it immediately: even an assignment or printf can replace the observation.

Most Bash pipeline stages run in subshell environments. An assignment in a loop on the right side of a pipe normally does not update the caller’s variable. Bash’s lastpipe option can alter the final stage’s execution when job control is inactive, so state assumptions need an explicit shell configuration. A redirected loop can avoid a pipeline when the caller must retain the loop’s state.

Finally, a foreground Bash pipeline waits for its stages to terminate. It does not return merely because the consumer read its first line. A producer that catches a broken pipe and continues unrelated work can delay completion. Treat a pipeline as several processes with connected descriptors and separate outcomes, rather than one command that necessarily succeeds or stops as a unit.

Check it quickly

Run the following Bash block with cat, yes, and head available. It compares default and pipefail statuses using a producer that deliberately exits seven. It then demonstrates two failing stages and an early-closing consumer. Errexit is disabled only while collecting expected nonzero results, then restored before assertions.

bash --noprofile --norc <<'BASH'
set -e
set +o pipefail
set +e
(printf 'partial\n'; exit 7) | cat >/dev/null
plain=("$?" "${PIPESTATUS[@]}")
set -e
[[ ${plain[*]} == '0 7 0' ]]
set -o pipefail
set +e
(printf 'partial\n'; exit 7) | cat >/dev/null
strict=("$?" "${PIPESTATUS[@]}")
set -e
[[ ${strict[*]} == '7 7 0' ]]
set +e
(exit 7) | (exit 4)
multiple=("$?" "${PIPESTATUS[@]}")
set -e
[[ ${multiple[*]} == '4 7 4' ]]
set +e
yes | head -n 1 >/dev/null
early=("$?" "${PIPESTATUS[@]}")
set -e
[[ ${early[0]} -ne 0 && ${early[1]} -ne 0 && ${early[2]} -eq 0 ]]
printf 'default: %s\npipefail: %s\nrightmost: %s\nearly close: %s\n' \
 "${plain[*]}" "${strict[*]}" "${multiple[*]}" "${early[*]}"
printf 'PASS: aggregate and individual stage outcomes\n'
BASH

Each reported array starts with the aggregate status, followed by the stages in source order. Expect 0 7 0, 7 7 0, and 4 7 4 for the first three. The final consumer succeeds while yes returns nonzero; the test deliberately does not require a platform-specific signal number. A production pipeline must distinguish this intentional early closure from lost required output. Measure throughput and memory separately; these status assertions do not measure buffering performance.

Sources

GNU Bash: Pipelines, process execution and aggregate status rules, checked 2026-09-06.
Linux man-pages: pipe(7), byte streams, descriptor lifetime, capacity, and SIGPIPE, checked 2026-09-06.
GNU Bash: Special Parameters, the immediately preceding command’s status, checked 2026-09-06.

Environment variables are a per-process thing

Sat, 25 Sep 2027 00:00:00 +0000

An environment is a collection of name-value strings supplied to a program when it starts. A child normally receives the environment selected by its parent; changing that child’s copy does not rewrite the parent’s or a sibling’s copy. This is a useful configuration boundary, but it is not a promise that the command has no side effects. The program can still modify shared files, databases, or other resources using those settings.

Export selects values for another program

A shell variable and an environment entry are related but distinct. Assigning DEMO_SETTING=local creates or updates a shell parameter. export DEMO_SETTING marks it for inclusion when the shell launches external commands. A new Bash process normally cannot see an unexported shell variable, even though the parent can print it. Merely placing an assignment in a configuration file does not load that file into every shell.

A value inherited through the environment is already marked for export by Bash. Changing its value retains that attribute, so a later grandchild can inherit the changed value without another export statement. unset removes the variable; Bash’s export -n removes its export attribute while retaining the shell value. The relevant question is which environment the immediate launcher supplied, not whether every ancestor repeated an export command.

A subshell is not a freshly executed shell

Parenthesized command groups and command substitution run in a subshell environment copied from the current shell. They can see ordinary shell variables that were never exported. Their assignments still do not flow back into the outer shell. This differs from executing a separate shell program, which receives exported entries rather than a complete copy of the parent’s shell parameter table.

Sourcing a file with . runs its commands in the current shell. Its assignments can therefore change the caller directly; it is not an exception to process isolation because no separate process is returning those changes. A sourced file is executable shell code, not passive configuration. Only source a file whose contents you intend to execute in that context.

Per-command settings have a defined lifetime

A prefix such as DEMO_SETTING=once external-command supplies a value for that invocation without permanently changing the surrounding shell’s value. This statement concerns an external command; assignment behavior around special builtins and functions has additional shell-specific rules. Do not generalize it into a claim that every command-looking construct creates an isolated process.

At the operating system interface, execve takes an explicit environment array and replaces the current process image. It does not itself create a new process. A launcher can preserve, filter, or replace the environment, which explains why privilege boundaries, service managers, and container configuration may produce values different from an interactive terminal. Process ancestry alone is insufficient to establish the actual settings delivered to an application.

When it breaks

Editing a terminal’s environment does not update an already running service. Likewise, changing an environment file has no effect until the relevant launcher rereads it and starts the process, unless the application provides its own reload mechanism. Check the configuration path used by that service and verify the resulting behavior in the process that actually handles requests.

Treat missing and empty values separately, because applications may assign them different meanings. Environment strings cannot contain an embedded NUL, and platforms limit the combined argument and environment size, so they are unsuitable for arbitrary binary payloads or unbounded documents. Inspect only the specific nonsecret keys needed for diagnosis; dumping an entire environment can expose credentials inherited by unrelated tools.

Check it quickly

Run this Bash example. It prints only a dedicated demonstration variable, uses no external configuration file, and leaves the surrounding terminal unchanged. The small here-document passed to . contains the complete trusted configuration used for the sourcing test.

BASH_ENV= bash --noprofile --norc <<'BASH'
unset DEMO_SETTING
DEMO_SETTING=local
printf 'shell=%s\n' "$DEMO_SETTING"
bash --noprofile --norc -c 'printf "unexported-child=%s\n" "${DEMO_SETTING-unset}"'
(printf 'subshell=%s\n' "$DEMO_SETTING")
export DEMO_SETTING
bash --noprofile --norc <<'CHILD'
printf 'exported-child=%s\n' "$DEMO_SETTING"
DEMO_SETTING=child
bash --noprofile --norc -c 'printf "grandchild=%s\n" "$DEMO_SETTING"'
CHILD
printf 'parent-after-child=%s\n' "$DEMO_SETTING"
DEMO_SETTING=once bash --noprofile --norc -c 'printf "one-command=%s\n" "$DEMO_SETTING"'
printf 'parent-after-command=%s\n' "$DEMO_SETTING"
. /dev/stdin <<'CONFIG'
DEMO_SETTING=sourced
CONFIG
printf 'parent-after-source=%s\n' "$DEMO_SETTING"
BASH

The unexported child prints unset, while the parenthesized subshell sees local. After export, the new child sees local, changes its own copy, and passes child to its grandchild. The outer shell remains local. The one-command override prints once, and the following parent check is still local.

Finally, sourcing changes that outer child shell’s value to sourced. Together these observations distinguish shell parameters, exported entries, subshell copies, per-command overrides, and execution in the current shell. They establish variable scope, not the absence of application side effects or the correctness of a service’s deployment configuration.

Sources

Bash execution environment, exported entries versus the state copied into subshells, checked 2026-09-07.
Bash environment, export attributes and per-command assignments, checked 2026-09-07.
POSIX exec functions, process-image replacement and explicit environment arrays, checked 2026-09-07.

Process groups select signal recipients, not a family tree

Fri, 24 Sep 2027 00:00:00 +0000

A process group is a kernel-maintained set of processes identified by a process group ID, or PGID. It provides a target for operations such as delivering a signal to a job. Parent-child relationships and group membership are separate: related processes can occupy different groups, and a group’s leader does not need to remain alive for other members to continue belonging to it.

When it breaks

Signaling a process does not automatically signal its children. Signaling its group selects current group members, not every descendant in the process tree. A child that starts another session or group can be outside that target. Conversely, multiple siblings can deliberately share a group even though neither sibling is the other’s parent.

Group delivery also does not guarantee a uniform response. One member can use the signal’s default action, another can install a handler, and another can ignore or block an eligible signal. The operation therefore does not atomically stop a job or prove that all its work completed. Per-process dispositions and the application’s shutdown protocol still determine the outcome.

The leader’s exit is not the group’s exit. A PGID can remain meaningful while another member survives, even after the leader is reaped. Supervisors that watch only the leader’s status may report completion while a member continues running. Group identity should be combined with actual lifecycle management rather than treated as a permanent identifier for all work launched together.

Check it quickly

Save this as groups.py and run python3 groups.py in a disposable Linux environment with Python 3.11 or later. The recorded run used Linux 6.12.76 and Python 3.11.2. Python’s process_group option assigns groups before execution, while start_new_session requests a new session. Every signaled process is a child created by this fixture:

import os,signal,subprocess,sys

worker=r'''
import os,signal,sys
if sys.argv[1]=='ignore-term':signal.signal(signal.SIGTERM,signal.SIG_IGN)
signal.signal(signal.SIGUSR1,lambda *_:print('USR1',flush=True))
print(os.getpid(),os.getpgrp(),os.getsid(0),flush=True)
while True:signal.pause()
'''
children=[]
def launch(role,**settings):
 process=subprocess.Popen([sys.executable,'-c',worker,role],stdout=subprocess.PIPE,stderr=subprocess.PIPE,text=True,**settings)
 children.append(process)
 identity=tuple(map(int,process.stdout.readline().split()))
 assert len(identity)==3 and identity[0]==process.pid
 return process,identity
try:
 leader,first=launch('default',process_group=0)
 member,second=launch('ignore-term',process_group=leader.pid)
 outsider,third=launch('default',start_new_session=True)
 group=leader.pid
 assert first[1]==second[1]==group and first[2]==second[2]==os.getsid(0)
 assert third==(outsider.pid,outsider.pid,outsider.pid)
 assert group!=os.getpgrp() and third[1]!=group
 print('two sibling children share a group; another sibling starts a separate session and group')
 os.killpg(group,signal.SIGTERM)
 assert leader.wait(timeout=5)==-signal.SIGTERM
 assert member.poll() is None and outsider.poll() is None
 assert os.getpgid(member.pid)==group
 print('group TERM terminates the default recipient, leaves the ignoring member alive, and excludes the other group')
 os.killpg(group,signal.SIGUSR1)
 assert member.stdout.readline().strip()=='USR1'
 print('the group remains addressable after its leader has exited and been reaped')
 os.killpg(group,signal.SIGKILL)
 assert member.wait(timeout=5)==-signal.SIGKILL
 assert outsider.poll() is None
 outsider.terminate();assert outsider.wait(timeout=5)==-signal.SIGTERM
 print('cleanup reaps all three children; signaling a group did not signal the whole family tree')
finally:
 for process in children:
 if process.poll() is None:process.kill();process.wait()

The first child starts a new process group whose PGID equals its PID. The second child joins that group within the controller’s session. The third child starts a separate session, becoming both its session leader and process-group leader. The script reads actual PID, PGID, and session ID values rather than assuming the requested arrangement took effect.

All three are siblings launched by the same controller. The first two share a signal target, while the third does not. This configuration makes the difference between parenthood and group membership explicit. The script also asserts that the target PGID differs from the controller’s own group, so the group operation cannot accidentally target its controlling process.

Sending TERM to the shared group terminates the first child, which uses the default disposition. The second deliberately ignores TERM and remains alive, as does the child outside the group. The controller waits for and reaps the first child, then confirms that the surviving member still reports the departed leader’s PID as its PGID.

A subsequent group-directed USR1 reaches that surviving member, whose installed handler prints an acknowledgment. This establishes that the group remains addressable after the leader has exited. The example uses a handler acknowledgment for this particular request instead of inferring application response solely from the signal-sending call’s successful return.

Finally, KILL terminates the remaining group member while leaving the separate-session child alive. The controller terminates that third child individually and reaps all three. Cleanup also handles an assertion failure. The result demonstrates selective group targeting and differing dispositions, without requiring a terminal or sending a signal to unrelated host processes.

Separate sessions, terminals, and supervision

setpgid changes membership subject to session and process-state restrictions. setsid creates a new session and group for an eligible caller; a process-group leader cannot use it directly. Creating a session does not change who a process’s parent is. Reparenting, terminal association, and group selection are related operational concerns, but they are not one interchangeable action.

An interactive shell with job control typically places a pipeline in its own group and assigns the terminal’s foreground PGID. The terminal driver delivers configured control-character signals to that foreground group. A noninteractive shell does not universally create one group per pipeline, so the grouping policy must be verified in the actual launch mode.

Signal permissions remain per recipient. Linux documents group-send success as delivery to at least one eligible process; it is not acknowledgment from every member. Use the appropriate service manager or an explicit child-management protocol when completion matters, and observe exits or application acknowledgments. A convenient group target helps control a job, but does not replace tracking its real members and outcomes.

Sources

setpgid(2), process-group membership, inheritance, and session restrictions, checked 2026-09-12.
setsid(2), creating a session and group, with process-group-leader restrictions, checked 2026-09-12.
kill(2), group-directed delivery, permission checks, and success semantics, checked 2026-09-12.
credentials(7), process IDs, groups, sessions, and controlling terminals, checked 2026-09-12.

Set file limits in the process that starts the workload

Mon, 19 Jul 2027 00:00:00 +0000

A shell’s ulimit builtin changes resource limits for that shell and the processes it subsequently starts. For file descriptors, RLIMIT_NOFILE has a current soft value and a hard ceiling. Understanding where those values are inherited is essential when a terminal reports a generous limit but an independently managed service still fails to open files or accept connections.

When it breaks

The soft value is the limit normally enforced for new descriptor allocation. An unprivileged process can raise its soft value only within the existing hard ceiling and can lower its hard limit. Raising a hard limit requires the relevant authority and remains subject to kernel constraints. A low hard value inherited at startup can therefore prevent the application from applying its intended soft setting.

Changing a child’s limit does not change the parent that launched it. Likewise, a command in a newly opened terminal does not retroactively configure a daemon started by systemd. The service’s actual parent and launch configuration determine its initial limits. A shell profile only has an effect when the launch path actually reads and applies that profile.

Bash option selection matters too. Reading ulimit -n normally reports the soft value, but assigning a value without selecting -S or -H changes both soft and hard limits. An operator intending a temporary soft reduction can accidentally lower the hard ceiling as well. Check the shell’s documented behavior instead of treating every similar-looking command as equivalent.

Check it quickly

Run this Python script as an administrator in a disposable Linux container with Bash and Python installed. It launches one experiment under an unprivileged numeric identity and leaves the administrator controller’s limits unchanged. The recorded environment used Linux 6.12.76, Bash 5.2.15, and Python 3.11.2. No existing account configuration or service unit is edited:

import resource,subprocess

before=resource.getrlimit(resource.RLIMIT_NOFILE)
assert before[0]>=64 and before[1]>=64
script=r'''
set -eu
ulimit -S -n 32
ulimit -H -n 64
python3 - <<'CHILD'
import resource
assert resource.getrlimit(resource.RLIMIT_NOFILE)==(32,64)
resource.setrlimit(resource.RLIMIT_NOFILE,(48,64))
assert resource.getrlimit(resource.RLIMIT_NOFILE)==(48,64)
print('first child inherits 32/64 and raises its own soft limit to 48')
CHILD
python3 - <<'CHILD'
import resource
assert resource.getrlimit(resource.RLIMIT_NOFILE)==(32,64)
print('second child still inherits shell values 32/64')
CHILD
if ulimit -S -n 65 2>/dev/null; then exit 11; fi
if ulimit -H -n 128 2>/dev/null; then exit 12; fi
(
 ulimit -n 16
 python3 - <<'CHILD'
import resource
assert resource.getrlimit(resource.RLIMIT_NOFILE)==(16,16)
print('Bash assignment without -S/-H changed both limits in this subshell')
CHILD
)
python3 - <<'CHILD'
import resource
assert resource.getrlimit(resource.RLIMIT_NOFILE)==(32,64)
print('parent shell limits survived child changes and rejected invalid increases')
CHILD
'''
# Run the experiment under an unprivileged numeric identity in this disposable container.
result=subprocess.run(['bash','--noprofile','--norc','-c',script],user=61001,group=61001,extra_groups=[],
 env={'PATH':'/usr/bin:/bin','LC_ALL':'C'},capture_output=True,text=True,timeout=10)
assert result.returncode==0,(result.returncode,result.stderr)
assert resource.getrlimit(resource.RLIMIT_NOFILE)==before
print(result.stdout,end='')
print('administrator controller limits remain unchanged')

The test shell starts by explicitly setting soft 32 and hard 64. Its first Python child inherits that pair, then successfully raises its own soft limit to 48 while keeping hard 64. This demonstrates an allowed increase within the ceiling; it does not require administrative authority inside the child.

A second Python child, launched by the same shell, still receives 32 and 64. The first child’s change stayed in that child, so there is no reverse propagation to the shell or its later children. Both observations read the actual resource-limit API rather than inferring values from the text of a startup script.

Attempts to set soft 65 above hard 64 and to raise the hard value to 128 are rejected in the unprivileged shell. The fixture checks the commands’ failure results. It does not suppress an error and then pretend the larger values were applied, and it does not rely on root accidentally making an otherwise forbidden operation succeed.

Within a subshell, ulimit -n 16 changes both values to 16. After that subshell ends, another child of the original test shell still sees 32 and 64. This separates two rules that often become confused: an assignment can affect both limit fields, while its process-local scope still prevents it from rewriting the parent.

Finally, the administrator controller compares its original limits with its current pair and confirms they are unchanged. All reductions and rejected increases occurred in disposable child processes. The exercise validates inheritance and permission rules, not a production server’s required descriptor budget or the behavior of every possible shell implementation.

Configure and inspect the real launch path

For a systemd service, configure the appropriate LimitNOFILE value in its effective unit settings and start a replacement process when that startup policy changes. For a shell-launched application, apply the intended setting in the launch path before execution. A one-time terminal command is not persistent configuration unless something deliberately runs it again on the next launch.

Inspect the target process’s limits, such as through /proc/PID/limits, and correlate them with the correct running instance. Reading the control shell’s limit answers a different question. Container runtime settings, user managers, and intermediate wrappers can each affect inheritance, so trace the actual process chain when expected values differ.

Choose a budget that includes sockets, ordinary files, pipes, event descriptors, and operational headroom. Raising the ceiling consumes no descriptors by itself, but allowing more live work can increase memory and downstream load. Validate the application’s event mechanism and ownership discipline as well as the numbers; higher limits are useful when the workload can use them correctly.

Sources

getrlimit(2), soft and hard resource limits, privilege checks, and inheritance, checked 2026-09-12.
GNU Bash builtins, ulimit soft/hard selection and assignment behavior, checked 2026-09-12.
systemd 252 execution environment, LimitNOFILE and service-manager execution limits, checked 2026-09-12.

File descriptors name a process’s open references

Sun, 21 Feb 2027 00:00:00 +0000

A file descriptor is a small integer used within one process to refer to an open resource. The process’s descriptor table maps that number to an open file description maintained by the kernel. For a regular file, the description includes the current offset and file status flags. Another process can use the same integer for a completely different resource, so the number alone is not a global file identity.

When it breaks

dup allocates another descriptor referring to the same open file description; it does not simply copy the integer or reopen the pathname. Reads through the two descriptors therefore share a regular file’s offset. By contrast, opening the same pathname again normally creates another description with its own offset. Equal device/inode identity does not imply equal open-description state.

Status flags and descriptor flags also live at different levels. An F_SETFL change to a shared open description is visible through duplicated references. The close-on-exec flag belongs to each descriptor separately. Confusing these layers can change another consumer’s behavior or unintentionally expose a descriptor to a subsequently executed program.

Closing a descriptor releases that table entry, and its integer can immediately be reused. Code retaining only a stale number may then operate on a new resource instead of reliably receiving a bad-descriptor error. Ownership and lifetime rules are essential when descriptors pass between callbacks, threads, or libraries; checking that an integer is nonnegative is not sufficient validation.

Check it quickly

Run this Python script in a disposable Linux environment. It creates two harmless temporary files and closes every descriptor it opens. The recorded environment used Linux 6.12.76 with Python 3.11.2. The exercise runs without background threads so allocation and reuse can be inspected without another thread racing to consume the released descriptor number:

from pathlib import Path
from tempfile import TemporaryDirectory
import fcntl,os

with TemporaryDirectory(prefix='xbcatm-fds-') as directory:
 root=Path(directory);original=root/'original';other=root/'other'
 original.write_bytes(b'abcdef');other.write_bytes(b'replacement')
 handles=set()
 try:
 first=os.open(original,os.O_RDONLY);handles.add(first)
 duplicate=os.dup(first);handles.add(duplicate)
 independent=os.open(original,os.O_RDONLY);handles.add(independent)
 assert first!=duplicate
 assert os.read(first,2)==b'ab' and os.read(duplicate,2)==b'cd'
 assert os.read(independent,2)==b'ab'
 assert os.lseek(first,0,os.SEEK_CUR)==4
 print('dup uses a different descriptor but shares offset; a separate open has its own offset')
 flags=fcntl.fcntl(duplicate,fcntl.F_GETFL)
 fcntl.fcntl(duplicate,fcntl.F_SETFL,flags|os.O_NONBLOCK)
 assert fcntl.fcntl(first,fcntl.F_GETFL)&os.O_NONBLOCK
 assert not fcntl.fcntl(independent,fcntl.F_GETFL)&os.O_NONBLOCK
 os.set_inheritable(first,False);os.set_inheritable(duplicate,True)
 assert not os.get_inheritable(first) and os.get_inheritable(duplicate)
 print('file status flags shared by dup; close-on-exec flags remain descriptor-specific')
 os.close(first);handles.remove(first)
 reused=os.open(other,os.O_RDONLY);handles.add(reused)
 assert reused==first and os.read(first,32)==b'replacement'
 assert os.read(duplicate,2)==b'ef'
 print('closed descriptor number is reused for another file; surviving duplicate still reads original')
 original.unlink();os.lseek(duplicate,0,os.SEEK_SET)
 assert os.fstat(duplicate).st_nlink==0 and os.read(duplicate,32)==b'abcdef'
 print('unlink removes the pathname while an open descriptor retains access')
 finally:
 for handle in handles:os.close(handle)

The first open reads ab, and its duplicate then reads cd. Both now observe offset four. A separate open of the same file still reads ab from its own initial position. These exact bytes establish which state is shared; merely seeing that both paths contain the same data would not distinguish duplicated references from independent opens.

The script sets O_NONBLOCK through the duplicate and observes the flag through the first descriptor, while the independent open retains its previous flags. For this regular-file fixture, the test concerns flag ownership, not a claim that ordinary disk reads become asynchronous. It then gives the duplicate a different inheritable setting and confirms that the original descriptor’s close-on-exec behavior is unchanged.

After the first descriptor closes, opening the other file reuses that integer. Reading through the stale variable now returns replacement, while the surviving duplicate still reads the original file’s final ef. This is a concrete demonstration of why a closed integer is not a durable reference to an object that used to exist.

Unlinking the original pathname removes its directory entry. The duplicate’s file status reports link count zero, yet seeking and reading through it still returns abcdef. Other open references in the fixture also remain valid until closed. Removing a name, closing one descriptor, and releasing the final open reference are distinct operations.

The script keeps an explicit set of currently owned descriptors for cleanup, removing the closed entry before its number is reused. That avoids accidentally treating the reused integer as two separately owned handles. Real code needs the same clarity when a function transfers ownership or a wrapper is responsible for closing its underlying descriptor.

Define ownership at the handoff

Document whether a function borrows a descriptor or takes responsibility for closing it. Use scoped wrappers where their ownership model fits, and avoid having two independent owners both close the same integer. Duplicating a reference can separate descriptor lifetime, but it still shares open-description state unless a genuinely independent open is intended.

Choose inheritance explicitly when starting another program. Language runtimes may create descriptors as non-inheritable, and subprocess APIs may close all except an allowed set. Verify the actual launch behavior rather than assuming that fork, exec, and a high-level process API expose identical descriptors.

Finally, match operations to the resource type. A pipe or socket is addressed through a descriptor too, but it does not acquire a regular file’s seekable offset contract. Correct descriptor handling combines resource semantics, open-description state, and a clear rule for who may close each process-local handle.

Sources

open(2), process descriptor tables, open file descriptions, offsets, and flags, checked 2026-09-12.
dup(2), new descriptor allocation, shared descriptions, and descriptor flags, checked 2026-09-12.
unlink(2), removing names while open references retain the file, checked 2026-09-12.

Process · XB Field Notes

Socket activation passes a listener to a compatible service

When it breaks

Check it quickly

Design the handoff and shutdown together

Further reading

Sources

Fork creates a process; exec replaces its program

When it breaks

Check it quickly

Make launch ownership explicit

Sources

Umask filters new permissions, with a default ACL exception

When it breaks

Check it quickly

Apply creation policy at the right layer

Sources

Shell pipes stream between processes

A byte stream with finite capacity

When it breaks

Check it quickly

Sources

Environment variables are a per-process thing

Export selects values for another program

A subshell is not a freshly executed shell

Per-command settings have a defined lifetime

When it breaks

Check it quickly

Sources

Process groups select signal recipients, not a family tree

When it breaks

Check it quickly

Separate sessions, terminals, and supervision

Sources

Set file limits in the process that starts the workload

When it breaks

Check it quickly

Configure and inspect the real launch path

Sources

File descriptors name a process’s open references

When it breaks

Check it quickly

Define ownership at the handoff

Sources