Check: Linux fundamentals

SIGTERM is a request. A process can catch it, flush its files, close connections and exit on its own. SIGKILL is handled by the kernel, the process never even sees it, so no cleanup happens. Hence the rule: try kill PID first (that's SIGTERM), and only if the process doesn't exit, kill -9 PID.

Below, the test subject process catches SIGTERM and prints cleanup before exiting:

docker run --rm ubuntu:24.04 bash -c 'bash -c "trap \"echo cleanup; exit 0\" TERM; while :; do sleep 0.1; done" & sleep 0.5; kill -TERM $!; wait $!; echo rc=$?'

cleanup
rc=0

Swap -TERM for -KILL and run it again:

bash: line 1:     7 Killed                  bash -c "trap \"echo cleanup; exit 0\" TERM; while :; do sleep 0.1; done"
rc=137

There's no cleanup line. Code 137 is 128 + 9, meaning "killed by signal 9".

A zombie is already dead and uses no resources. All that's left is a slot in the process table, until the parent calls wait(). You can't kill it with a signal, not even kill -9: there's nothing left to kill. Restarting the parent helps. Then the zombie gets reparented to PID 1, which collects its return code, and the entry disappears.

Let's make a zombie by hand. sleep 1 goes to the background, and its parent turns into sleep 5 (via exec) and never calls wait():

docker run --rm ubuntu:24.04 bash -c '(sleep 1 & exec sleep 5) & sleep 2; ps -o pid,ppid,stat,cmd'

    PID    PPID STAT CMD
      1       0 Rs   ps -o pid,ppid,stat,cmd
      7       1 S    sleep 5
      9       7 Z    [sleep] <defunct>

The letter Z in the STAT column and the <defunct> tag. The PPID column has the parent's number: that's who you need to deal with.

Each digit is a sum: r = 4, w = 2, x = 1. So 6 is rw-, and 4 is r--. The three digits go in order: owner, group, others. That gives rw-r--r--, the usual permissions for a text file or a config with no secrets.

docker run --rm ubuntu:24.04 bash -c 'touch f; chmod 644 f; ls -l f'

-rw-r--r-- 1 root root 0 Oct  9 07:52 f

Your date will be different.

Permissions 755 already give everyone x, so 777 adds nothing except a hole: now anyone can write to the script. Root has nothing to do with it either, 755 lets everyone run it. On a partition mounted with noexec, the kernel won't run anything, no matter the permissions. Check it with findmnt -T: the OPTIONS column will show noexec.

docker run --rm --tmpfs /work ubuntu:24.04 bash -c 'cd /work; printf "#!/bin/bash\necho hi\n" > s.sh; chmod 755 s.sh; ./s.sh; findmnt -T s.sh'

bash: line 1: ./s.sh: Permission denied
TARGET SOURCE FSTYPE OPTIONS
/work  tmpfs  tmpfs  rw,nosuid,nodev,noexec,relatime

Conveniently, docker run --tmpfs mounts the directory with noexec.

But a script with no shebang will run fine from bash. The kernel doesn't recognize the file's format and returns an error, bash sees that and runs the file as a shell script itself:

docker run --rm ubuntu:24.04 bash -c 'echo "echo hi" > s.sh; chmod 755 s.sh; ./s.sh'

hi

Put the shebang in anyway: without it, the script runs under whatever shell started it, not the one it was written for. Another common reason ./script.sh fails to run is Windows line endings in the shebang (covered in the permissions lesson, "Common mistakes" section). That's a different error: not Permission denied, but required file not found or bad interpreter.

> empties the file before writing, so it's easy to wipe out what you needed. >> appends to the end and leaves the old content alone. Logs and anything that accumulates need >>.

docker run --rm ubuntu:24.04 bash -c 'echo one > f.txt; echo two > f.txt; cat f.txt; echo ---; echo three >> f.txt; cat f.txt'

two
---
two
three

There's no one line: the second > wiped it.

Redirects run left to right. > out.log points stdout (stream 1) to the file. Then 2>&1 sends stderr (stream 2) wherever stream 1 currently points, which is now the file too. If you swap the order, 2>&1 > out.log, stderr goes wherever stdout pointed before the file: the screen.

docker run --rm ubuntu:24.04 bash -c 'ls /root /nope > out.log 2>&1; cat out.log; echo ---; ls /root /nope 2>&1 > out2.log; echo ---; cat out2.log'

ls: cannot access '/nope': No such file or directory
/root:
---
ls: cannot access '/nope': No such file or directory
---
/root:

In the first case, the error sits in the file. In the second, it went to the screen before cat ever ran, and only the regular output ended up in out2.log.