跪拜 Guibai
← Back to the summary

The Shell Engineer's Toolkit, Part 2: Processes, Networks, and System State

In the previous article, we discussed file operations and text processing, which are the most frequently used commands for a shell engineer on a daily basis. This article changes the topic to three other equally important areas: process management, network tools, and system information.

These three areas make up the other half of daily operations. When writing scripts, besides handling files, you will most likely also need to interact with running programs—checking processes, networks, and system status. Mastering the commands in this article will allow your shell scripts to cover 90% of operational scenarios.

1. Commonality Among the Three Types of Tools

Commands for processes, networks, and system information may seem unrelated, but they actually share one common characteristic: they all "observe and control a running system." Unlike the previous article's focus on "operating on static files," the commands here often:

Therefore, the commands in this article must be used more cautiously. We will proceed in the order of "observation → control": first learn how to view, then learn how to act.

2. Process Management

Processes are the entities a shell engineer deals with most. Your script, once started, is a process; calling an external command creates a child process; deployed services are also processes. Understanding the state of processes and their relationships is the foundation for writing reliable scripts.

2.1 ps: Viewing Processes

ps stands for process status. It lists the processes currently in the system. The syntax is ps [options].

The most commonly used combinations:

# View all processes of the current user
ps
​
# View all processes (including other users)
ps -ef
# or
ps aux
​
# Find a specific process
ps -ef | grep nginx

ps -ef and ps aux are two mainstream styles; the former is System V style, the latter is BSD style. The output columns differ, but both are usable. For daily use, ps -ef is recommended for better cross-platform compatibility.

Output field interpretation (using ps -ef as an example):

UID    PID  PPID  C STIME TTY      STAT   TIME     CMD
root     1     0  0 Aug22 ?        00:00:01 /sbin/init
root   123     1  0 Aug22 ?        00:00:00 nginx: master process

Several practical query combinations:

# Filter by process name
ps -ef | grep -v grep | grep nginx
​
# Filter by user
ps -u www-data
​
# Query details by PID
ps -p 1234 -o pid,ppid,cmd
​
# Custom output columns
ps -eo pid,ppid,user,pcpu,pmem,cmd --sort=-pcpu | head

The last line is especially common—finding the processes consuming the most CPU.

2.2 top / htop: Dynamic Viewing

ps is a one-time snapshot, while top is a dynamically refreshing "real-time monitor."

top                  # Start top, default 3-second refresh
top -p 1234          # Monitor only a specific PID
top -u www-data      # Monitor only a specific user
top -n 1             # Refresh only once (suitable for scripts)

top's output is divided into two parts: the upper half is the system overall (load, CPU, memory), and the lower half is the process list. Key points to watch:

Several interactive commands in top:

htop is an upgraded version of top—supports mouse, color, and tree view. If htop is available, use htop; the experience is much better than top. Installation: apt install htop or yum install htop.

2.3 jobs / fg / bg: Foreground/Background Switching

This is the shell's own process management, separate from the operating system's process management.

# Start a background task
sleep 100 &
​
# View background tasks of the current shell
jobs
# Output: [1]+ Running    sleep 100 &
​
# Bring a background task to the foreground
fg %1
​
# Send a foreground task to the background (first pause with Ctrl+Z)
# Press Ctrl+Z
bg %1

& means "start in the background." jobs lists the background tasks of the current shell (note: only the current shell; tasks in a subshell are not visible).

Key concept: A foreground task occupies the terminal; pressing Ctrl+C kills it. A background task does not occupy the terminal; Ctrl+C does not affect it. Therefore, long-running tasks should be placed in the background using &.

But a background task might be killed by SIGHUP when the terminal closes—the solution is nohup, discussed later.

2.4 nohup: Detaching from the Terminal

nohup long_running.sh &

nohup makes the process ignore the SIGHUP signal—it won't be killed when the terminal disconnects, and & makes it run in the background. This is the standard combination for "starting a service that can run for a long time."

Output is written to nohup.out by default, unless you redirect it:

nohup long_running.sh > /var/log/myservice.log 2>&1 &

Note that nohup is not a cure-all; it only handles SIGHUP, not other signals. A true daemon process needs to use systemd or a dedicated daemon tool.

2.5 kill / pkill / killall: Sending Signals

The original purpose of kill is to "send a signal," not to "kill a process"—sending the TERM signal is just its default behavior. The details were covered in the previous article on signals; here we only discuss practical usage.

# Send TERM (default, graceful exit)
kill 1234
​
# Send KILL (force, signal 9)
kill -9 1234
​
# Send HUP (reload configuration, common for nginx/apache)
kill -HUP 1234
​
# Kill by name
pkill nginx
​
# Force kill all matches
pkill -9 nginx
​
# Kill an entire process group (e.g., kill all child processes started by a script)
kill -- -1234   # Note the negative sign

Several safety practices:

2.6 nice / renice: Adjusting Priority

nice adjusts process priority (niceness value), ranging from -20 to 19. A higher value means lower priority and less CPU contention. Regular users can only increase the value (lower priority), while root can adjust to any value.

# Set priority at startup
nice -n 19 long_running.sh &
​
# Adjust priority of a running process
renice -n 10 -p 1234

When to use: For batch tasks, scheduled tasks, backup scripts, and other processes that should not affect the main business, increase the nice value to let them run politely.

3. Network Tools

Another major task for a shell engineer is dealing with networks—calling APIs, transferring files, checking connections, querying DNS. This section goes over the most commonly used network tools.

3.1 ping: Basic Connectivity

# Simple ping
ping example.com
​
# Limit count
ping -c 4 example.com
​
# Set interval
ping -i 0.5 example.com
​
# Do not resolve domain name (pure IP ping)
ping -n 8.8.8.8

Practical usage of ping:

# Wait for a service to start (polling + ping)
until ping -c 1 -W 1 myservice.local &>/dev/null; do
    sleep 1
done
echo "Service is ready"

But note that ping does not necessarily reflect the true state of a service. A host being pingable doesn't mean a port is reachable (firewalls may block ICMP). Use curl or nc to test service availability.

3.2 curl / wget: HTTP Clients

Both curl and wget are HTTP clients, but curl is more general-purpose, while wget is more focused on downloading.

# Simple GET
curl https://example.com
​
# Follow redirects
curl -L https://example.com
​
# Output HTTP headers
curl -I https://example.com
​
# POST request
curl -X POST -d 'name=alice&age=25' https://api.example.com/users
​
# JSON POST
curl -X POST -H 'Content-Type: application/json' \
    -d '{"name":"alice","age":25}' \
    https://api.example.com/users
​
# Carry cookies
curl -b cookies.txt -c cookies.txt https://example.com
​
# Show detailed request
curl -v https://example.com
​
# Download a file
curl -O https://example.com/file.zip
curl -o myfile.zip https://example.com/file.zip

Common curl options:

Several practical curl combinations:

# Test API health
curl -sf https://api.example.com/health || echo "API unhealthy"
​
# Call API and parse JSON (with jq)
curl -s https://api.example.com/users | jq '.[] | .name'
​
# Download with rate limiting
curl --limit-rate 1M -O https://example.com/bigfile.zip
​
# Follow redirects
curl -L -o file.html https://bit.ly/shortlink

-f means "return non-zero on failure." Used with set -e, the script will exit immediately if curl fails. This is the standard practice for calling APIs in shell scripts.

Choosing between wget and curl: curl has more features and supports more protocols (FTP, SFTP, SMTP, etc.), while wget focuses on HTTP downloads and is simpler for recursive downloads. Use curl for daily API calls, and wget for batch downloads.

3.3 ssh / scp / rsync: Remote Operations

ssh is the most common remote login tool, scp is file transfer based on ssh, and rsync is a more powerful synchronization tool.

# Log in remotely
ssh user@host
​
# Specify port
ssh -p 2222 user@host
​
# Execute a remote command
ssh user@host 'ls -la'
​
# Copy file to remote
scp file.txt user@host:/remote/path/
​
# Copy file from remote
scp user@host:/remote/file.txt ./
​
# Copy directory
scp -r dir/ user@host:/remote/path/

Several practical ssh tips:

# Passwordless login (using keys)
ssh-keygen -t ed25519                 # Generate key
ssh-copy-id user@host                 # Upload public key
​
# SSH config file (~/.ssh/config)
Host myserver
    HostName 192.168.1.100
    User alice
    Port 2222
    IdentityFile ~/.ssh/work_key
​
# Use alias directly after configuration
ssh myserver
scp file.txt myserver:/tmp/

rsync is much more powerful than scp—incremental sync, preserving permissions, resumable transfers.

# Local sync
rsync -av src/ dst/
​
# Remote sync
rsync -av -e ssh src/ user@host:/remote/path/
​
# Delete extra files in the destination
rsync -av --delete src/ dst/
​
# Exclude certain files
rsync -av --exclude='*.tmp' src/ dst/
​
# Dry run (see which files would be synced without actually doing it)
rsync -avn src/ dst/

Key rsync options:

Classic rsync usage:

# Backup script (run daily)
rsync -av --delete /data/ /backup/data/
​
# Deploy to multiple servers
for host in server1 server2 server3; do
    rsync -az -e ssh ./app/ $host:/opt/app/
done

3.4 ss / netstat: Network Connections

ss is the new-generation tool for viewing network connections (replacing netstat). netstat is gradually being phased out on new systems—if ss is available on the system, use ss.

# View all TCP connections
ss -t
​
# View all listening ports
ss -tlnp
​
# View all UDP connections
ss -u
​
# View established connections
ss -t state established
​
# Filter by port
ss -tlnp 'sport = :80'
​
# Count connections by state
ss -tan | awk '{print $1}' | sort | uniq -c

Output difference between ss and netstat: netstat combines "address" and "port" into one column, while ss separates them into two. ss is better for machine readability, making awk parsing simpler.

3.5 dig / nslookup / host: DNS Queries

# Query A record
dig example.com
​
# Short output
dig +short example.com
​
# Query specific record types
dig example.com MX
dig example.com TXT
​
# Specify DNS server
dig @8.8.8.8 example.com
​
# Reverse DNS (IP to domain name)
dig -x 8.8.8.8

host is a more concise version, with friendlier output:

host example.com
host 8.8.8.8

nslookup is the oldest and is generally not recommended now. dig provides the most complete information and is the first choice when troubleshooting DNS issues.

3.6 nc / ncat: The Network Swiss Army Knife

nc (netcat) is a low-level network tool that can read and write TCP/UDP connections. It is particularly useful when debugging network issues.

# Listen on a port (as a server)
nc -l 12345
​
# Connect to a port (as a client)
nc example.com 80
​
# Port scan
nc -zv example.com 80-100
​
# File transfer (simple two-end)
# Receiving end
nc -l 12345 > file.txt
# Sending end
nc host 12345 < file.txt

Practical usage of nc:

# Test if a port is open
nc -zv example.com 80
​
# Debug HTTP requests (send manually)
printf "GET / HTTP/1.0\r\nHost: example.com\r\n\r\n" | nc example.com 80
​
# Wait for a service to start (more reliable than ping)
until nc -z myservice 8080; do
    sleep 1
done

4. System Information

The last group of commands is for checking system status—checking the kernel, memory, disk, and users. These are often used in daily scripts for "environment checks."

4.1 uname: System Information

# System information
uname -a
​
# View kernel alone
uname -r
​
# View hostname alone
uname -n

4.2 hostname: Host Name

hostname                # Display hostname
hostname -I             # Display all IP addresses
hostname -f             # Display fully qualified domain name (FQDN)

4.3 date / uptime: Time Information

date                    # Current time
date +%Y-%m-%d          # Formatted output
date +%s                # Unix timestamp
date -d "2024-01-15"    # Parse string to date
date -d "@1704067200"   # Timestamp to date
date -u                 # UTC time
date -R                 # RFC 2822 format
​
uptime                  # System uptime and load

Common usage of date in scripts:

# Log file with date suffix
log_file="app_$(date +%Y%m%d).log"
​
# Calculate time difference
start=$(date +%s)
do_something
end=$(date +%s)
echo "Time elapsed $((end - start)) seconds"
​
# Time 7 days ago
date -d "7 days ago" +%Y-%m-%d

4.4 who / whoami / id: User Information

whoami                  # Current username
id                      # Detailed info (UID, GID, groups)
who                     # Logged-in users
w                       # More detailed login info

id is most commonly used in scripts—to check if the current user is root:

if [ "$(id -u)" -ne 0 ]; then
    echo "Please run with root privileges"
    exit 1
fi

4.5 free: Memory

free                    # Memory usage
free -h                 # Human-readable
free -m                 # In MB
free -s 5               # Refresh every 5 seconds

Output fields: total total memory, used used, free free, shared shared, buff/cache buffers/cache, available available. Note that available is the "truly usable" memory—you must account for buff/cache to get the accurate figure.

4.6 df / du: Disk

The previous article covered the basic usage of df and du. Here are a few additional combinations:

# View disk IO statistics
iostat
​
# View filesystem type
df -T
​
# Find the 5 largest files
find /var -type f -exec du -h {} + | sort -rh | head -5
​
# Find files larger than 1G
find / -type f -size +1G 2>/dev/null

4.7 lscpu / lsblk / lspci: Hardware Information

lscpu                   # CPU info
lsblk                   # Block device (disk) info
lspci                   # PCI devices
lsusb                   # USB devices

These commands are occasionally used when troubleshooting hardware issues, but are not commonly used in daily scripts.

4.8 /proc Filesystem

Linux exposes process and kernel information under /proc—the output of many commands is actually read from here.

# Current process info
cat /proc/self/status
​
# CPU info
cat /proc/cpuinfo
​
# Memory info
cat /proc/meminfo
​
# System uptime
cat /proc/uptime
​
# Process command line
cat /proc/1234/cmdline

Reading /proc in a script is more efficient than calling commands—no need to fork a process. For example, to determine system uptime:

uptime_seconds=$(awk '{print $1}' /proc/uptime)

5. Summary

In this article, we covered three more groups of commonly used commands:

As with the previous article, the key is not to memorize every parameter of every command, but to know when to use which one and how to combine them.

The next article is the final part of this series—covering archiving, compression, permissions, users, and a few advanced tools (xargs, tee, cron, screen/tmux). This is the last set of pieces for the shell toolbox. After writing these three articles, your mastery of daily shell commands will be complete.