Traps and temporary files - clean exit on signal or error · Linux

Scripts that crash mid-execution leave temporary files behind. Trap handlers clean up. Atomic operations prevent partial writes. This lesson covers both.

mktemp

Safe temporary files:

# Create a temporary file
TMPFILE=$(mktemp)
echo "data" > "$TMPFILE"

# Create a temporary directory. Name it anything EXCEPT TMPDIR -
# see the warning below.
workdir=$(mktemp -d)
cp /etc/passwd "$workdir/passwd"

# Create with a template
TMPFILE=$(mktemp -t my-script.XXXXXX)

mktemp creates files with mode 600 and unique names. Predictable names like /tmp/foo are race-condition risks.

Never call your scratch directory TMPDIR

TMPDIR is the environment variable mktemp and most of the standard toolchain consult to decide where temporary files go. Assigning your own scratch directory to it redirects every subsequent mktemp - and every child process - into the exact directory your trap is about to rm -rf:

# WRONG
TMPDIR=$(mktemp -d)
trap 'rm -rf "$TMPDIR"' EXIT
report=$(mktemp)         # lands INSIDE $TMPDIR, and is deleted with it

Whether it bites depends on whether TMPDIR was already exported in your environment - which it often is, under systemd PrivateTmp=, in CI runners, and in desktop sessions. That makes it an intermittent bug: the script works on your laptop and loses its output on the build agent. Use workdir, scratch, or anything else.

trap for cleanup

workdir=$(mktemp -d)
trap 'rm -rf "$workdir"' EXIT INT TERM

# Use $workdir...
# Cleanup runs automatically on exit

trap '...' EXIT runs on any exit - success, error, signal. INT is Ctrl-C. TERM is kill.

Multiple commands in one trap:

cleanup() {
    rm -rf "$workdir"
    log "Cleaned up"
}
trap cleanup EXIT INT TERM

Atomic file operations

When updating a config file, use atomic writes:

mv is atomic only within one filesystem. Across filesystems it degrades to copy-then-unlink, and a reader that opens the file mid-copy sees a truncated config. Bare mktemp puts the file under $TMPDIR, which is /tmp — a separate tmpfs on a hardened build — so mv /tmp/x /etc/myapp.conf is exactly the non-atomic case. Create the staging file in the destination directory instead:

dst=/etc/myapp.conf
tmp=$(mktemp "${dst}.XXXXXX")     # same directory, therefore same filesystem
trap 'rm -f "$tmp"' EXIT

printf '%s\n' "new content" > "$tmp"

# Inherit the real file's identity, not root:root 0600 from mktemp
chown --reference="$dst" "$tmp" 2>/dev/null || true
chmod --reference="$dst" "$tmp" 2>/dev/null || chmod 0644 "$tmp"
command -v restorecon >/dev/null && restorecon "$tmp"

mv -f -- "$tmp" "$dst"            # atomic

The three lines before the mv are not decoration. mktemp creates mode 0600 owned by the caller, so the naive version silently changes the config’s owner and permissions. On an SELinux host a file created under /tmp carries the tmp_t label; move it to /etc and it keeps tmp_t, and the daemon that reads it is denied — a failure that looks like file corruption and is actually a label.

After the mv, the destination is either the old file or the new file, never a partial one.

Some applications can reload config without restart:

mv -f -- "$tmp" "$dst"
systemctl reload myapp

Common pitfalls

Predictable temp files: /tmp/my-script.tmp is a race condition. Two instances may write to the same file, and a hostile local user can pre-create it as a symlink. Use mktemp. Lock files are the exception - see the next section: a lock needs a fixed, shared path, so the safety comes from flock, not from a unique name.
No cleanup: a script that crashes mid-way leaves files. Use trap.
Non-atomic writes: writing to the destination directly means a crash mid-write leaves a partial file. Write to temp, then rename.
Trap misconfiguration: trap 'rm -rf "$workdir"' (no EXIT) only runs on the signal, not on normal exit. Always include EXIT.
Naming your scratch directory TMPDIR: it redirects every later mktemp into the directory your trap deletes.
Staging in /tmp and moving to /etc: that crosses a filesystem boundary, so the mv is not atomic and the file arrives with the wrong owner and SELinux label.

Safe lock file

A lock file prevents two instances running simultaneously. Use flock, and nothing else:

# The path is fixed and shared - that is the point of a lock
exec 9>/run/lock/my-script.lock
flock -n 9 || { echo "Already running"; exit 0; }

# Work here. No trap, no cleanup, no rm.
# The kernel releases the lock when the process dies -
# including on SIGKILL, on a crash, and on power loss.

The fd stays open for the lifetime of the process and the lock lives on the open file description, not on the file’s existence. That is why no cleanup is needed and why flock survives the failure modes a hand-rolled lock does not.

Note the exit 0. A second instance finding the lock held is usually normal, not an error - exiting non-zero from cron turns every overlap into an email or a failed-unit alert.

Two lock patterns that look right and are not

Pattern one - mktemp as a lock:

# WRONG - always reports "Already running", on every run
LOCKFILE=$(mktemp -t my-script.lock.XXXXXX)
if [[ -e "$LOCKFILE" ]]; then
    err "Already running"
fi

mktemp creates the file it names. The -e test is therefore always true, so this script exits on its very first invocation and every one after it. And because mktemp returns a fresh unique path each time, the test could never see another instance’s lock even if the file did not exist. This is not a race - it is a job that never runs. The symptom is the cruel part: “Already running” is a normal, expected message, so monitoring and on-call treat weeks of skipped backups as benign.

Pattern two - deleting the lock file at exit:

# WRONG - unlinking the lock file breaks mutual exclusion
exec 200>/var/lock/my-script.lock
flock -n 200 || err "Already running"
trap "flock -u 200; rm -f /var/lock/my-script.lock" EXIT

flock locks an inode, not a name. Once the file is unlinked, a process still holding the lock is holding it on an inode nobody can reach any more, while the next process creates a brand-new file at that path and locks that instead. Both then run at once. Never unlink a lock file, and never flock -u before exiting - process death releases the lock for you.

If you would rather not manage the fd yourself, flock can wrap the command directly - the usual form in a crontab:

flock -n /run/lock/my-script.lock /usr/local/bin/my-script