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. ...
A setuid binary runs with the identity of its owner rather than of whoever started it. The kernel swaps credentials at exec time, which is how passwd rewrites /etc/shadow without an ordinary user holding write permission on it. The bit belongs to the file, and it grants the owner’s entire identity, not one narrow ability. ...
The sticky bit on a Linux directory adds an ownership restriction to removing or renaming entries. It is commonly combined with broad directory write and search permissions so several users can create temporary files without freely removing one another’s entries. The directory permission check and the sticky ownership check both matter; sticky is an additional condition, not a replacement for normal access control. ...
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. ...
“Command not found” identifies a lookup failure, but lookup does not always mean walking every directory in PATH. In ordinary Bash, a command word without a slash can resolve to a function, builtin, cached executable path, or a newly searched executable. An alias may already have changed the command while the input was read. Inspect the shell that actually reported the failure before reinstalling a tool that may already exist. ...
Graceful shutdown is a transition in how a service accepts and finishes work. Receiving a signal is only the trigger. The useful guarantee is narrower than “nothing is lost”: stop admitting new business work, account for what was already accepted, allow bounded completion, and report honestly when that bound expires. ...
Durable application state and disposable scratch files need different retention, capacity, and recovery policies. Separating their paths makes those policies easier to express, but directories alone do not create persistence or isolate disk capacity. The storage backing each path determines what survives process restart, container replacement, host failure, or cleanup. A reliable layout connects each class of data to an explicit lifecycle. ...
Configuration that is easy to find, read, and diff is more than a preference; it is how a change stays reviewable. Naming a file with a clear convention is the first step to environment-specific, single-source config. A file is a record of intent A named, versioned config file is a record of intent: the deployed values become explicit, reviewable, and reproducible just like code. When the file lives with the project, a change gets history, a blame, and a pull request, so anyone can answer ‘what actually shipped and who changed it’. A clear naming convention (app.conf for application knobs, app.env for environment shape) makes each file’s purpose obvious at a glance, and keeps the settings from being scattered into ad-hoc flags nobody can find. ...