Permissions and Processes

File Permissions

Every file and directory in Linux has an owner, a group, and a permission set. Understanding permissions is essential when test scripts fail with "Permission denied" or when you need to make a script executable.

Reading Permission Strings

ls -la tests/
# -rw-r--r--  1 qa  dev  4096 Jan 15 10:00 login.spec.ts
# drwxr-xr-x  2 qa  dev  4096 Jan 15 10:00 fixtures/

The permission string -rw-r--r-- breaks down as:

Position	Meaning	Example
1	File type (`-` = file, `d` = directory, `l` = symlink)	`-`
2-4	Owner permissions (read/write/execute)	`rw-` (read + write, no execute)
5-7	Group permissions	`r--` (read only)
8-10	Others permissions	`r--` (read only)

Permission Values

Symbol	Meaning	Numeric Value
`r`	Read	4
`w`	Write	2
`x`	Execute	1
`-`	No permission	0

Numeric permissions are the sum of the values. For example:

rwx = 4 + 2 + 1 = 7 (full access)
rw- = 4 + 2 + 0 = 6 (read + write)
r-- = 4 + 0 + 0 = 4 (read only)
r-x = 4 + 0 + 1 = 5 (read + execute)

Changing Permissions

# Make a script executable
chmod +x run-tests.sh

# Give owner full access, group read+execute, others nothing
chmod 750 run-tests.sh
# Owner: rwx (7), Group: r-x (5), Others: --- (0)

# Make a file readable only by the owner (sensitive config)
chmod 600 credentials.json
# Owner: rw- (6), Group: --- (0), Others: --- (0)

# Recursively set permissions on a directory
chmod -R 755 scripts/

# Change owner of test results directory
chown -R qa:dev test-results/
# Now the 'qa' user and 'dev' group own the directory and its contents

Common Permission Scenarios for QA

Scenario	Command	Why
Script won't run	`chmod +x script.sh`	Script needs execute permission
CI fails with "Permission denied"	`chmod 755 scripts/`	Runner user lacks permissions
Sensitive file exposed	`chmod 600 .env`	Restrict access to owner only
Test artifacts not writable	`chown -R $(whoami) test-results/`	Wrong owner from previous run

Process Management

Understanding processes helps you debug test infrastructure issues: "Why won't my test server start?" often leads to "something else is using that port."

Viewing Processes

# List running processes
ps aux
# USER  PID  %CPU %MEM  COMMAND
# qa    1234  2.1  1.5  node server.js
# qa    5678  0.5  0.8  npx playwright test

# Filter processes by name
ps aux | grep node
ps aux | grep playwright

# Interactive process viewer (like task manager)
top

# More user-friendly alternative (may need to install)
htop

Process Details

# See detailed info about a specific process
ps -p 1234 -o pid,ppid,user,%cpu,%mem,command

# See all processes in a tree (parent-child relationships)
ps auxf

# See environment variables of a running process
cat /proc/1234/environ | tr '\0' '\n'

Port Management

"Port already in use" is one of the most common QA frustrations. Here is how to diagnose and fix it.

# Find what is using port 3000 (your test server won't start)
lsof -i :3000
# COMMAND  PID  USER  TYPE  DEVICE  NODE  NAME
# node     1234  qa   IPv4  12345   TCP   *:3000 (LISTEN)

# Alternative command
ss -tlnp | grep 3000
# LISTEN  0  128  *:3000  *:*  users:(("node",pid=1234,fd=15))

# Find all listening ports
ss -tlnp

# Find processes using a port range
lsof -i :3000-3100

Killing Processes

# Graceful shutdown (SIGTERM) -- lets the process clean up
kill 1234

# Force kill (SIGKILL) -- immediate termination, use as last resort
kill -9 1234

# Kill by name
pkill -f "node server.js"

# Kill all processes matching a pattern
pkill -f "playwright"

# Kill the process using a specific port
kill $(lsof -t -i :3000)

Always try graceful shutdown first. kill -9 does not let the process clean up (close database connections, save state, release locks). Use it only when kill does not work.

Background Processes

# Run a process in the background
node server.js &
# Output: [1] 1234 (job number and PID)

# List background jobs
jobs
# [1]+  Running  node server.js &

# Bring a background job to foreground
fg %1

# Send a running foreground process to background
# Press Ctrl+Z (suspends the process)
bg %1  # Resume it in the background

# Run a process that survives terminal disconnect
nohup node server.js > server.log 2>&1 &
# Output goes to server.log, process continues even if you close the terminal

System Resources

When tests are slow or failing due to resource constraints, check system resources.

# Memory usage
free -h
#               total    used    free    available
# Mem:          16Gi     12Gi    1.2Gi   3.5Gi
# Swap:         4.0Gi    0.5Gi   3.5Gi

# CPU usage per core
mpstat -P ALL

# IO statistics (disk read/write)
iostat -x 1 5  # Report every 1 second, 5 times

# Overall system load
uptime
# 14:30:00 up 23 days, load average: 2.45, 1.87, 1.23
# Load averages: 1 minute, 5 minutes, 15 minutes
# If load average > number of CPU cores, system is overloaded

Resource-Related Test Failures

Symptom	Check	Likely Cause
Tests timeout randomly	`free -h`	Low memory, swapping
Tests slow on CI	`uptime`	High load average, shared runner
"No space left on device"	`df -h`	Disk full (test artifacts, Docker images)
"Cannot allocate memory"	`free -h`	Out of RAM (too many browser instances)
"Too many open files"	`ulimit -n`	File descriptor limit reached

Network Diagnostics

# Check if a host is reachable
ping staging.example.com

# Check DNS resolution
nslookup staging.example.com
dig staging.example.com

# Check if a port is open on a remote host
nc -zv staging.example.com 443

# Trace the network path to a host
traceroute staging.example.com

# Check your machine's IP addresses
ip addr show
# Or on macOS:
ifconfig

# Test HTTP connectivity
curl -I https://staging.example.com

Hands-On Exercise

List all files in your home directory with full permission details. Identify which files you own and their permissions.
Create a script test.sh with echo "Hello". Try to run it. Fix the permission error. Run it again.
Find what process is using port 8080 on your machine. If nothing is, start a simple server and verify.
Check your system's memory and disk usage. Is anything close to capacity?
Run a process in the background, list it with jobs, bring it to the foreground, and then kill it.
Use ss -tlnp to list all services listening on your machine. Identify each one.