Sometimes the change you need is already written, just on the wrong branch. A hotfix may land on main when it also needs to go to a maintenance branch, or a useful commit may be buried in a feature branch that you do not want to merge wholesale. In that situation, git cherry-pick lets you copy the effect of a specific commit onto your current branch.

This guide explains how git cherry-pick works, how to apply one or more commits safely, and how to handle the conflicts that can appear along the way.

Syntax #

The general syntax for git cherry-pick is:

git cherry-pick [OPTIONS] COMMIT...

• OPTIONS - Flags that change how Git applies the commit.
• COMMIT - One or more commit hashes, branch references, or commit ranges.

git cherry-pick replays the changes introduced by the selected commit on top of your current branch. Git creates a new commit, so the result has a different commit hash even when the file changes are the same.

Cherry-Picking a Single Commit #

Start by finding the commit you want to copy. This example lists the recent commits on a feature branch:

git log --oneline feature/auth

a3f1c92 Fix null pointer in auth handler
d8b22e1 Add login form validation
7c4e003 Refactor session logic

The output gives you the abbreviated commit hashes. In this case, a3f1c92 is the fix we want to move.

Switch to the target branch before running git cherry-pick:

git switch main
git cherry-pick a3f1c92

[main 9b2d4f1] Fix null pointer in auth handler
Date: Tue Apr 14 10:42:00 2026 +0200
1 file changed, 2 insertions(+)

Git applies the change from a3f1c92 to main and creates a new commit, 9b2d4f1. The subject line is the same, but the commit hash is different because the parent commit is different.

Cherry-Picking Multiple Commits #

If you need more than one non-consecutive commit, pass each hash in the order you want Git to apply them:

git cherry-pick a3f1c92 d8b22e1

Git creates a separate new commit for each one. This works well when you need a few targeted fixes but do not want the rest of the source branch.

For a range of consecutive commits, use the range notation:

git cherry-pick a3f1c92^..7c4e003

This tells Git to include a3f1c92 and every commit after it up to 7c4e003. If you omit the caret, the starting commit itself is excluded:

git cherry-pick a3f1c92..7c4e003

That form applies every commit after a3f1c92 through 7c4e003.

Applying Changes Without Committing #

Sometimes you want the changes from a commit, but not an automatic commit for each one. Use --no-commit (or -n) to apply the changes to your working tree and staging area without creating the commit yet:

git cherry-pick --no-commit a3f1c92

This is useful when you want to combine several small fixes into one commit on the target branch, or when you need to edit the files before committing.

After reviewing the result, create the commit yourself:

git status
git commit -m "Backport auth null-check fix"

This gives you more control over the final commit message and lets you group related backports together.

Recording Where the Commit Came From #

For maintenance branches and backports, it is often helpful to keep a reference to the original commit. Use -x to append the source commit hash to the new commit message:

git cherry-pick -x a3f1c92

Git adds a line like this to the new commit message:

(cherry picked from commit a3f1c92...)

That extra line makes future audits easier, especially when you need to prove that a fix on a release branch came from a reviewed change on another branch.

Cherry-Picking a Merge Commit #

Cherry-picking a regular commit is straightforward, but merge commits need one extra option. Git must know which parent to treat as the main line:

git cherry-pick -m 1 MERGE_COMMIT_HASH

• -m 1 - Use the first parent as the base, which is usually the branch that received the merge.
• -m 2 - Use the second parent instead.

If you are not sure which parent is which, inspect the history first:

git log --oneline --graph

Cherry-picking merge commits is more advanced and easier to get wrong. If the goal is to bring over an entire merged feature, a normal merge is often clearer than cherry-picking the merge commit itself.

Resolving Conflicts #

If the target branch has changed in the same area of code, Git may stop and ask you to resolve a conflict:

error: could not apply a3f1c92... Fix null pointer in auth handler
hint: After resolving the conflicts, mark them with
hint: "git add/rm <pathspec>", then run
hint: "git cherry-pick --continue".

Open the conflicted file and look for the conflict markers:

<<<<<<< HEAD
return session.getUser();
=======
if (session == null) return null;
return session.getUser();
>>>>>>> a3f1c92 (Fix null pointer in auth handler)

Edit the file to keep the final version you want, then stage it and continue:

git add src/auth.js
git cherry-pick --continue

If you decide the commit is not worth applying after all, abort the operation:

git cherry-pick --abort

git cherry-pick --abort puts the branch back where it was before the cherry-pick started.

A Safe Backport Workflow #

When you cherry-pick onto a release or maintenance branch, slow down and make the source obvious. A simple workflow looks like this:

git switch release/1.4
git pull --ff-only
git cherry-pick -x a3f1c92
git status

The important part is the sequence. Start from the branch that needs the fix, make sure it is up to date, cherry-pick with -x, then review and test the branch before pushing it. This avoids the common mistake of copying a fix into an outdated branch and shipping an untested backport.

If the picked commit depends on earlier refactors or new APIs that are not present on the target branch, stop there. In that case, either copy the prerequisite commits too or recreate the fix manually.

When to Use git cherry-pick #

git cherry-pick is a good fit when you need a precise change without the rest of the branch:

• Backporting a bug fix from main to a release branch
• Recovering one useful commit from an abandoned feature branch
• Moving a small fix that was committed on the wrong branch
• Pulling a reviewed change into a hotfix branch without merging unrelated work

Avoid it when the target branch needs the full context of the source branch. If the commit depends on earlier commits, shared refactors, or schema changes, a merge or rebase is usually the cleaner option.

Troubleshooting #

error: could not apply ... during cherry-pick
The target branch has conflicting changes. Resolve the files Git marks as conflicted, stage them with git add, then run git cherry-pick --continue.

Cherry-pick created duplicate-looking history
That is normal. Cherry-pick copies the effect of a commit, not the original object. The new commit has a different hash because it has a different parent.

The picked commit does not build on the target branch
The commit likely depends on earlier work that is missing from the target branch. Inspect the source branch history with git log and either cherry-pick the prerequisites too or reimplement the change manually.

You picked the wrong commit
If the cherry-pick already completed, use git revert on the new commit. If the operation is still in progress, use git cherry-pick --abort.

Quick Reference #

For a printable quick reference, see the Git cheatsheet .

FAQ #

What is the difference between git cherry-pick and git merge?
git cherry-pick copies the effect of selected commits onto your current branch. git merge joins two branch histories and brings over all commits that are missing from the target branch.

Does cherry-pick change the original commit?
No. The source commit stays exactly where it is. Git creates a new commit on your current branch with the same file changes.

Should I use -x every time?
Not always, but it is a good habit for backports and maintenance branches. It gives you a clear link back to the original commit.

Can I cherry-pick commits from another remote branch?
Yes. Fetch the remote branch first, then cherry-pick the commit hash you want. You can inspect the incoming history with git log or review the file changes with git diff before applying anything.

Conclusion #

git cherry-pick is the tool to reach for when one commit matters more than the branch it came from. Use it for targeted fixes, keep -x in mind for backports, and fall back to merge or rebase when the change depends on broader branch context.

If your server is open to the public network, it needs a firewall. On Ubuntu and Debian, the easiest way to set one up is with ufw. This tool sits on top of iptables (or nftables on newer systems) and replaces complex rules with simple, easy-to-read commands.

This guide walks through the ufw command, from enabling the firewall and setting default policies to writing rules for ports, services, and specific addresses.

ufw Syntax #

The general form of the command is:

sudo ufw [OPTIONS] COMMAND [ARGS]

• OPTIONS - Flags such as --dry-run to preview what a rule would do.
• COMMAND - The action, for example enable, allow, deny, delete, or status.
• ARGS - The rule body, such as a port number, a service name, or a full rule specification.

ufw changes firewall rules, so almost every invocation needs sudo.

Checking the Firewall Status #

Before you touch the rules, check whether the firewall is running and what is already in place:

sudo ufw status

If ufw is inactive, you will see:

Status: inactive

This confirms that ufw is installed but not currently enforcing any firewall rules.

Once active, the same command lists the rules:

Status: active
To Action From
-- ------ ----
22/tcp ALLOW Anywhere
80/tcp ALLOW Anywhere
22/tcp (v6) ALLOW Anywhere (v6)
80/tcp (v6) ALLOW Anywhere (v6)

For a numbered view that is easier to reference when deleting rules, use:

sudo ufw status numbered

And for a more detailed output that shows default policies and logging level:

sudo ufw status verbose

Enabling and Disabling the Firewall #

The first time you enable ufw, make sure you have already allowed SSH. Enabling the firewall over an SSH session without an allow ssh rule will lock you out of the server.

Allow SSH first:

sudo ufw allow ssh

Then turn the firewall on:

sudo ufw enable

Firewall is active and enabled on system startup

At this point, ufw starts enforcing the rules immediately and will come back automatically after a reboot.

To stop the firewall and clear it from the startup sequence:

sudo ufw disable

A disabled ufw keeps the rules you defined. When you re-enable it, the same rules come back.

Default Policies #

Default policies decide what happens to traffic that does not match any rule. The usual hardening is to deny incoming traffic and allow outgoing traffic:

sudo ufw default deny incoming
sudo ufw default allow outgoing

After running these two commands, you only need to open the specific inbound ports your server should expose. Outbound traffic still flows freely, which is what most servers need.

You can also set the default for forwarded traffic, which matters if the host acts as a router or runs containers:

sudo ufw default deny routed

Allowing Connections #

The allow command is the one you will use most often. It accepts a service name, a port, a protocol, or a full rule.

Allow a Service by Name #

ufw reads /etc/services and understands common service names:

sudo ufw allow ssh
sudo ufw allow http
sudo ufw allow https

Each command opens the matching port (22, 80, and 443) for both TCP and UDP where applicable.

Allow a Specific Port #

To open a port directly, pass the port number:

sudo ufw allow 8080

By default, this opens the port for both TCP and UDP. To limit it to one protocol, add /tcp or /udp:

sudo ufw allow 8080/tcp
sudo ufw allow 53/udp

Allow a Port Range #

Port ranges require an explicit protocol:

sudo ufw allow 6000:6007/tcp
sudo ufw allow 6000:6007/udp

The colon separates the start and the end of the range, both inclusive.

Allow Traffic From a Specific Address #

To accept connections from a single IP address, use from:

sudo ufw allow from 203.0.113.25

To restrict that to a single service, add to any port:

sudo ufw allow from 203.0.113.25 to any port 22

Allow Traffic From a Subnet #

CIDR notation works the same way for whole networks:

sudo ufw allow from 192.168.1.0/24 to any port 3306

This is a common pattern for databases: the port stays closed to the internet and is only reachable from your internal network.

Allow Traffic on a Specific Interface #

To tie a rule to a network interface, add on INTERFACE:

sudo ufw allow in on eth1 to any port 3306

The in keyword applies the rule to inbound traffic on eth1. Use out for outbound traffic.

Denying Connections #

The deny command is the mirror of allow and takes the same arguments:

sudo ufw deny 23
sudo ufw deny from 198.51.100.77

When the default incoming policy is already deny, you usually do not need to write explicit deny rules for closed ports. Explicit denies are useful when you want to block a specific address while keeping a port open to everyone else.

To log the denied packets instead of silently dropping them, use reject:

sudo ufw reject 23

A reject sends an ICMP message back to the sender, while a deny drops the packet with no response.

Rate Limiting SSH #

ufw can throttle repeated connections from the same IP, which is handy for SSH brute-force protection:

sudo ufw limit ssh

The limit rule denies a connection if the source address attempts six or more connections in 30 seconds. This is a quick way to slow down password-guessing bots without installing a full intrusion-prevention tool.

Deleting Rules #

There are two common ways to remove a rule. The first is to repeat the rule with delete in front:

sudo ufw delete allow 8080/tcp

The second is to delete by rule number:

sudo ufw status numbered

 To Action From
-- ------ ----
[ 1] 22/tcp ALLOW IN Anywhere
[ 2] 80/tcp ALLOW IN Anywhere
[ 3] 8080/tcp ALLOW IN Anywhere

sudo ufw delete 3

ufw asks for confirmation before removing the rule. Keep in mind that after a deletion, the numbering shifts for the remaining rules, so always check the numbered status again before deleting another rule.

For a deeper walkthrough, see how to list and delete UFW firewall rules .

Application Profiles #

Services that come with their own ufw profile can be referenced by name. List them with:

sudo ufw app list

Available applications:
Nginx Full
Nginx HTTP
Nginx HTTPS
OpenSSH

To open the ports that a profile covers, pass its name to allow:

sudo ufw allow 'Nginx Full'

Quote profile names that contain spaces. To see what ports a profile includes, use:

sudo ufw app info 'Nginx Full'

Dry Run #

Before you commit to a change, you can preview the iptables rules ufw would add with --dry-run:

sudo ufw --dry-run allow 8080/tcp

No rule is created. The output shows the exact lines ufw would write, which is useful when you are writing rules over SSH and want to double-check them first.

Logging #

ufw can log packets that match rules, which helps when troubleshooting. The log level can be adjusted:

sudo ufw logging on
sudo ufw logging medium

Valid levels are off, low, medium, high, and full. ufw logs through the kernel log facility, so the exact destination depends on your system logging setup. On many Ubuntu systems with rsyslog, you will see entries in /var/log/ufw.log, and you can often inspect them with journalctl as well.

Reset the Firewall #

To clear every rule and set ufw back to its fresh state, run:

sudo ufw reset

IPv6 Support #

On most modern systems, ufw can manage IPv6 rules as well as IPv4 rules. Check the setting in /etc/default/ufw:

IPV6=yes

When IPV6=yes, generic rules such as sudo ufw allow 22/tcp are created for both IPv4 and IPv6. Rules that include an explicit address stay specific to that address family. In the status output, the IPv6 rules appear with (v6) next to them.

Quick Reference #

For a printable quick reference, see the ufw cheatsheet .

Troubleshooting #

ufw: command not found
Install the ufw package with sudo apt install ufw on Ubuntu or Debian. On Fedora, RHEL, and derivatives, firewalld is the default and ufw is rarely used.

Locked out after enabling the firewall over SSH
The default deny policy blocked your SSH session. You will need console access to the server. Once in, run sudo ufw allow ssh and sudo ufw reload to restore access. The usual safeguard is to allow SSH before the first enable.

Rule added but traffic still blocked
Confirm the rule is in the right direction (inbound vs outbound) and on the right interface. Check with sudo ufw status verbose. If Docker is running, it writes its own iptables rules that can bypass ufw.

Changes do not take effect
After manual edits to /etc/ufw/ files, reload the firewall with sudo ufw reload. Commands issued through ufw apply immediately and do not need a reload.

FAQ #

Is ufw the same as iptables?
No. ufw is a front end that generates iptables (or nftables) rules for you. The kernel still enforces the rules through its packet filter, but you do not need to edit the raw tables yourself.

Does ufw start automatically after reboot?
Yes, once you run sudo ufw enable, the service is registered with systemd and starts on boot. You can confirm with systemctl status ufw.

How do I allow a port for a single IP address?
Use the from and to any port form: sudo ufw allow from 203.0.113.25 to any port 22. This keeps the port closed to the rest of the internet and only opens it for that one address.

What is the difference between deny and reject?
deny drops the packet without any reply. reject sends an ICMP message back to the sender telling them the connection was refused. Reject is slightly friendlier to well-behaved clients but makes the server more visible to scans.

How do I undo everything and start over?
Run sudo ufw reset. It disables the firewall and removes every rule. Remember to re-add the SSH rule before re-enabling, especially on a remote server.

Conclusion #

ufw keeps firewall management readable: allow what you need, deny what you do not, and lean on the default policies to cover the rest. If you want step-by-step instructions for setting it up on a new server, see how to set up a firewall with UFW on Ubuntu 24.04 .

When a website does not load or email stops arriving, the first thing to check is whether the domain resolves to the correct address. The nslookup command is a quick way to query DNS servers and inspect the records behind a domain name.

nslookup ships with most Linux distributions and works on macOS and Windows as well. It supports both one-off queries from the command line and an interactive mode for running multiple lookups in a row.

This guide explains how to use nslookup with practical examples covering record types, reverse lookups, and troubleshooting.

Syntax #

nslookup [OPTIONS] [NAME] [SERVER]

• NAME — The domain name or IP address to look up.
• SERVER — The DNS server to query. If omitted, nslookup uses the server configured in /etc/resolv.conf.
• OPTIONS — Query options such as -type=MX or -debug.

When called without arguments, nslookup starts in interactive mode.

Installing nslookup #

On most distributions nslookup is already installed. To check, run:

nslookup -version

If the command is not found, install it using your distribution’s package manager.

Install nslookup on Ubuntu, Debian, and Derivatives #

sudo apt update && sudo apt install dnsutils

Install nslookup on Fedora, RHEL, and Derivatives #

sudo dnf install bind-utils

Install nslookup on Arch Linux #

sudo pacman -S bind

The nslookup command is bundled with the same packages that provide dig .

Look Up a Domain Name #

The simplest use is passing a domain name as an argument:

nslookup linux.org

Server: 127.0.0.53
Address: 127.0.0.53#53
Non-authoritative answer:
Name: linux.org
Address: 104.26.14.72
Name: linux.org
Address: 104.26.15.72
Name: linux.org
Address: 172.67.73.26

The first two lines show the DNS server that answered the query. Everything under “Non-authoritative answer” is the actual result. In this case, linux.org resolves to three IPv4 addresses.

“Non-authoritative” means the answer came from a resolver’s cache rather than directly from the domain’s authoritative name server.

Query a Specific DNS Server #

By default, nslookup queries the resolver configured in /etc/resolv.conf. To query a different server, add it as the last argument.

For example, to query Google’s public DNS:

nslookup linux.org 8.8.8.8

Server: 8.8.8.8
Address: 8.8.8.8#53
Non-authoritative answer:
Name: linux.org
Address: 104.26.14.72
Name: linux.org
Address: 104.26.15.72
Name: linux.org
Address: 172.67.73.26

This is useful when you want to compare results across different resolvers or verify whether a DNS change has propagated to public servers.

Query Record Types #

By default, nslookup returns A (IPv4 address) records. Use the -type option to query other record types.

MX Records (Mail Servers) #

MX records identify the mail servers responsible for receiving email for a domain:

nslookup -type=mx google.com

Server: 127.0.0.53
Address: 127.0.0.53#53
Non-authoritative answer:
google.com mail exchanger = 10 smtp.google.com.

The number before the mail server hostname is the priority. A lower number means higher priority.

NS Records (Name Servers) #

NS records show which name servers are authoritative for a domain:

nslookup -type=ns google.com

Server: 127.0.0.53
Address: 127.0.0.53#53
Non-authoritative answer:
google.com nameserver = ns1.google.com.
google.com nameserver = ns2.google.com.
google.com nameserver = ns3.google.com.
google.com nameserver = ns4.google.com.

TXT Records #

TXT records store arbitrary text data, commonly used for SPF, DKIM, and domain ownership verification:

nslookup -type=txt google.com

Server: 127.0.0.53
Address: 127.0.0.53#53
Non-authoritative answer:
google.com text = "v=spf1 include:_spf.google.com ~all"
google.com text = "facebook-domain-verification=22rm551cu4k0ab0bxsw536tlds4h95"
google.com text = "docusign=05958488-4752-4ef2-95eb-aa7ba8a3bd0e"

The output may include many entries. The example above shows a subset of the TXT records returned for google.com.

AAAA Records (IPv6) #

AAAA records return the IPv6 address of a domain:

nslookup -type=aaaa google.com

Server: 127.0.0.53
Address: 127.0.0.53#53
Non-authoritative answer:
Name: google.com
Address: 2a00:1450:4017:818::200e

SOA Record (Start of Authority) #

The SOA record contains administrative information about the domain, including the primary name server, the responsible email address, and timing parameters for zone transfers:

nslookup -type=soa google.com

Server: 127.0.0.53
Address: 127.0.0.53#53
Non-authoritative answer:
google.com
origin = ns1.google.com
mail addr = dns-admin.google.com
serial = 897592583
refresh = 900
retry = 900
expire = 1800
minimum = 60

The serial number increments each time the zone is updated. DNS secondaries use it to decide whether they need a zone transfer.

CNAME Records #

CNAME records point one domain name to another:

nslookup -type=cname www.github.com

If a CNAME record exists, the output shows the canonical name the alias points to. If the domain does not have a CNAME record, nslookup returns No answer.

Run an ANY Query #

To ask the DNS server for an ANY response, use -type=any:

nslookup -type=any google.com

ANY queries do not reliably return every record type for a domain. Many DNS servers return only a subset of records or refuse the query entirely.

Reverse DNS Lookup #

A reverse lookup finds the hostname associated with an IP address. Pass an IP address instead of a domain name:

nslookup 208.118.235.148

148.235.118.208.in-addr.arpa name = ip-208-118-235-148.twdx.net.

Reverse lookups query PTR records. They are useful for verifying that an IP address maps back to the expected hostname, which matters for mail server configuration and security checks.

Interactive Mode #

Running nslookup without arguments starts an interactive session where you can run multiple queries without retyping the command:

nslookup

>

At the > prompt, type a domain name to look it up:

> linux.org
Server: 127.0.0.53
Address: 127.0.0.53#53
Non-authoritative answer:
Name: linux.org
Address: 104.26.14.72
Name: linux.org
Address: 104.26.15.72

You can change query settings during the session with the set command. For example, to switch to MX record lookups and then query a domain:

> set type=mx
> google.com
Server: 127.0.0.53
Address: 127.0.0.53#53
Non-authoritative answer:
google.com mail exchanger = 10 smtp.google.com.

To change the DNS server:

> server 8.8.8.8
Default server: 8.8.8.8
Address: 8.8.8.8#53

Type exit to leave interactive mode.

Interactive mode is convenient when you need to test several domains or record types in a row without running separate commands each time.

Debugging DNS Issues #

The -debug option shows the full query and response details, including TTL values and additional sections that nslookup normally hides:

nslookup -debug linux.org

The debug output is verbose, but it is helpful when you need to see TTL values, check whether answers are authoritative, or trace unexpected behavior.

nslookup vs dig #

Both nslookup and dig query DNS servers, but they differ in output and capabilities:

• nslookup produces simpler, more readable output. It also has an interactive mode that is convenient for quick checks.
• dig provides detailed, structured output with sections (QUESTION, ANSWER, AUTHORITY, ADDITIONAL) and supports advanced options like +trace for tracing the full resolution path and +dnssec for verifying DNSSEC signatures.

For quick lookups and basic troubleshooting, nslookup is often faster to type and read. For in-depth DNS debugging, dig gives you more control and detail.

Troubleshooting #

nslookup returns NXDOMAIN
The domain does not exist or is misspelled. Verify the domain name and check that it is registered.

nslookup returns SERVFAIL
The DNS server could not process the query. Try a different resolver to isolate the problem:

nslookup linux.org 1.1.1.1

If public resolvers return the correct answer, the issue is with your configured resolver.

Connection timed out; no servers could be reached
This means nslookup could not contact the DNS server. Check your network connection and verify that /etc/resolv.conf contains a reachable name server. A firewall may also be blocking outbound DNS traffic on port 53.

Non-authoritative answer appears on every query
This is normal. It means the answer came from a resolver’s cache, not directly from the domain’s authoritative server. The result is still valid.

Quick Reference #

For a printable quick reference, see the nslookup cheatsheet .

FAQ #

Can I use nslookup to check DNS propagation?
Yes. Query the same domain against several public DNS servers and compare the results. For example, run nslookup example.com 8.8.8.8, nslookup example.com 1.1.1.1, and nslookup example.com 9.9.9.9. If the answers differ, the change has not fully propagated.

Is nslookup deprecated?
The ISC (the organization behind BIND) once marked nslookup as deprecated in favor of dig, but later reversed that decision. nslookup is actively maintained and included in current BIND releases. It remains a practical tool for quick DNS lookups.

What does “Non-authoritative answer” mean?
It means the response came from a caching resolver, not from one of the domain’s authoritative name servers. The data is still accurate, but it may be slightly behind if a DNS change was made very recently and the cache has not expired yet.

Conclusion #

The nslookup command is a quick way to query DNS records from the command line. Use -type to look up MX, NS, TXT, AAAA, and other record types, and pass a server argument to test against a specific resolver. For deeper DNS debugging, pair it with dig .

If you are setting up a new Linux server, Debian and Ubuntu are usually the two options that come up first. Both are mature, well-supported, and used across everything from small VPS deployments to large production environments. They also share the same package format and package manager, so the day-to-day administration feels familiar on both.

The decision usually comes down to tradeoffs: Debian gives you a leaner and more conservative base, while Ubuntu gives you newer defaults, a broader support ecosystem, and easier onboarding. This guide shows where those differences matter in practice.

Shared Foundation #

Ubuntu is built on top of Debian. Canonical (the company behind Ubuntu) takes a snapshot of Debian’s unstable branch every six months, applies its own patches and defaults, and publishes a new Ubuntu release.

Because of this shared lineage, the two distributions have a lot in common:

• Both use apt and dpkg for package management.
• Both use systemd as the init system.
• Both use .deb packages, and many third-party vendors ship a single .deb that works on either distribution.
• Configuration file locations, service management commands, and filesystem layout follow the same conventions.

If you already know one, you can work comfortably on the other with very little adjustment.

Release Cycle and Support #

The biggest practical difference between Debian and Ubuntu is how often they release and how long each release is supported.

Debian does not follow a fixed release schedule. A new stable version ships roughly every two years, but only when the release team considers it ready. Each stable release receives approximately three years of full security support from the Debian Security Team, followed by about two more years of extended support through the Debian LTS project. Debian 13 (Trixie), released in August 2025, is the current stable version as of this writing. Debian 12 (Bookworm), released in June 2023, is now oldstable.

Ubuntu follows a predictable time-based schedule. A new version ships every six months (April and October), and every two years the April release is designated a Long-Term Support (LTS) version. LTS releases receive five years of free security updates, extendable to ten years through Ubuntu Pro (free for up to five machines for personal use). Ubuntu 24.04 LTS (Noble Numbat) is the current LTS release.

If you want a release calendar you can plan around years in advance, Ubuntu is easier to work with. If you prefer a slower release model that puts stability first, Debian is usually the better choice.

Package Freshness vs Stability #

Debian Stable freezes all package versions at release time. Once Bookworm shipped, its packages only receive security patches and critical bug fixes, never feature updates. This means you will not encounter unexpected behavior changes after a routine apt upgrade, but it also means you may be running older versions of languages, databases, or runtimes for the life of the release.

Ubuntu LTS takes a similar approach to stability, but because it pulls from a more recent Debian snapshot and applies its own patches, LTS packages tend to be slightly newer at release time. Ubuntu also offers PPAs (Personal Package Archives) as an official mechanism for installing newer software outside the main repository, though mixing PPAs with production servers carries its own risks.

Both distributions offer backports repositories for users who need specific newer packages without upgrading the entire system.

For server workloads where you install most software through containers or version managers (for example, nvm for Node.js or pyenv for Python), base package age matters less. The distribution becomes a stable foundation, and you manage application-level versions separately.

Default Installation and Setup #

Ubuntu Server ships with a guided installer (Subiquity) that walks you through disk layout, networking, user creation, and optional snap-based packages like Docker. It installs a small but functional set of tools by default and can import your SSH keys from GitHub or Launchpad during setup.

Debian’s installer is more traditional. It offers the same configuration options, but the interface is text-based and expects you to make more decisions yourself. The resulting system is leaner; Debian installs very little beyond the base system unless you explicitly select additional task groups during installation.

If you provision servers with tools like Ansible, Terraform, or cloud-init, the installer matters less because you will not spend much time in it after the first boot. It matters more for quick manual deployments and local VMs, where Ubuntu usually gets you to a usable system faster.

Commercial Support and Cloud Ecosystem #

Canonical offers paid support contracts, compliance certifications (FIPS, CIS benchmarks), and a managed services tier for Ubuntu. Ubuntu Pro extends security patching beyond the main repository and adds kernel livepatch for rebootless security updates. That matters most for teams with uptime targets, compliance requirements, or formal support needs.

Debian is entirely community-driven. There is no single company behind it, and there is no commercial support offering from the project itself. Third-party consultancies provide Debian support, but the ecosystem around it is smaller.

In the cloud, Ubuntu has a strong lead in first-party image availability. Every major provider (AWS, Google Cloud, Azure, DigitalOcean, Hetzner) offers official Ubuntu images, and many default to Ubuntu when launching a new instance. Debian images are also available on all major platforms, but Ubuntu tends to receive new platform features and optimized images first.

For container base images, both are widely used. Debian slim images are a popular choice for minimal Docker containers, while Ubuntu images are common when teams want closer parity between their server OS and their container environment.

Security #

Both distributions have strong security track records. The Debian Security Team and the Ubuntu Security Team publish advisories and patches regularly, and both maintain clear processes for reporting and fixing vulnerabilities.

The key difference is scope. Ubuntu LTS includes five years of standard security maintenance for packages in the Main repository. Ubuntu Pro extends coverage to Main and Universe, effectively the full Ubuntu archive. Debian’s security team focuses on the main repository, and Debian’s LTS team covers only a subset of packages during the extended support period.

For kernel security, Ubuntu offers kernel livepatch through Ubuntu Pro, which applies critical kernel fixes without a reboot. Debian does not have an equivalent service built into the project, though third-party solutions exist.

In practice, both distributions are secure when properly maintained. The difference is in how much of the maintenance is handled for you and for how long.

When to Choose Debian #

Choose Debian when you want:

• Maximum stability with few surprises after upgrades. Debian Stable is one of the most conservative general-purpose distributions available.
• A minimal base system that you build up yourself. Debian installs very little by default, which keeps the system lean and gives you tighter control over what runs on the server.
• No vendor dependency. Debian is maintained by a community of volunteers and governed by a social contract. There is no single company setting the direction of the project.
• A lightweight container base. Debian slim images are a common choice when image size matters.

Debian is often the better fit for long-running infrastructure, self-managed servers, and setups where predictability matters more than convenience.

When to Choose Ubuntu #

Choose Ubuntu when you want:

• Faster time to a working server. The installer and default configuration get you to a usable system quickly, especially on cloud platforms where Ubuntu images are often the default.
• Longer official support. Five years of free LTS support (ten with Ubuntu Pro) gives you a wider upgrade window than Debian’s default support period.
• Commercial backing. If your organization requires vendor support contracts, compliance certifications, or managed services, Canonical provides them.
• Broader documentation and community. Ubuntu’s larger user base means you will usually find more tutorials, examples, and third-party guides written for it.
• Cloud-heavy workflows. First-party cloud images and strong cloud-init support make Ubuntu an easy default for many hosted deployments.

Ubuntu is often the easier choice for cloud deployments, teams that need commercial support, and environments where onboarding speed matters.

Side-by-Side Summary #

FAQ #

Can I migrate a server from Ubuntu to Debian or vice versa?
It is technically possible but not straightforward. The distributions share the same package format, but they differ in package versions, configuration defaults, and init scripts. A clean reinstall with configuration management (Ansible, Puppet, or similar) is the safer path. Plan the migration as a new deployment rather than an in-place conversion.

Do Debian and Ubuntu run the same software?
For the most part, yes. Most common server software is available on both Debian and Ubuntu, whether through the official repositories, vendor-provided .deb packages, containers, or upstream binaries. That said, package versions, repository availability, and vendor support can differ between the two distributions and between releases.

Which is better for Docker and containers?
Both work well as Docker hosts. Installing Docker follows nearly the same steps on either distribution. For base images inside containers, Debian slim images are slightly smaller, while Ubuntu images offer closer parity with Ubuntu-based host systems. The difference is marginal for most workloads.

Which is more secure?
Neither is inherently more secure than the other. Both have dedicated security teams and fast patch turnaround. Ubuntu Pro extends patching to a wider package set and adds kernel livepatch, which can matter in environments with strict uptime or compliance requirements. On a properly maintained server, both are equally secure.

Conclusion #

Debian and Ubuntu are close enough that you can run the same kinds of workloads on either one. If you want the more conservative and self-managed option, pick Debian. If you want faster onboarding, broader vendor support, and a smoother cloud path, pick Ubuntu.

Linux

一、基础命令

1. Linux 基础命令

问题：Linux 基础命令

答案： 核心回答：ls、cd、pwd、mkdir、rm、cp、mv 是基础命令。

代码示例：

# 目录操作
ls -la                       # 详细列表
ls -lh                       # 人类可读大小
cd /path/to/dir              # 切换目录
pwd                          # 显示当前目录
mkdir -p /path/to/dir        # 创建目录
mkdir -m 755 dir             # 指定权限

# 文件操作
rm -rf dir                   # 删除目录
rm file.txt                   # 删除文件
cp -r source dest            # 复制目录
cp file.txt dest/             # 复制文件
mv oldname newname           # 重命名/移动

# 查看文件
cat file.txt                 # 全文
head -n 20 file.txt          # 前20行
tail -n 20 file.txt          # 后20行
tail -f /var/log/syslog      # 实时查看日志

# 搜索
grep "pattern" file.txt      # 搜索文本
find / -name "filename"     # 查找文件

2. 文件权限

问题：文件权限

答案： 核心回答：Linux 文件权限分为 owner、group、others 三类，各有 rwx 权限。

代码示例：

# 查看权限
ls -l file.txt
# -rw-r--r-- 1 user group 4096 Jan 15 10:00 file.txt
# 权限位: -rw-r--r--
# 类型  owner  group  others
# r=4 w=2 x=1

# 修改权限
chmod 755 file               # 数字形式
chmod u+x file               # 所有者添加执行
chmod g-w file               # 组移除写
chmod o+r file               # 其他添加读
chmod a+x file               # 所有添加执行

# 修改所有者
chown user:group file        # 修改所有者和组
chown user file              # 只修改所有者
chgrp group file             # 只修改组

# 特殊权限
chmod +s file               # SUID/SGID
chmod +t file               # Sticky Bit

二、文本处理

3. 文本处理命令

问题：文本处理命令

答案： 核心回答：awk、sed、grep 是强大的文本处理工具。

代码示例：

# awk - 文本分析
awk '{print $1, $3}' file.txt          # 打印第1、3列
awk -F',' '{print $2}' file.csv       # 指定分隔符
awk '/pattern/ {print $0}' file.txt   # 模式匹配
awk 'NR==5' file.txt                  # 第5行

# sed - 文本替换
sed 's/old/new/g' file.txt           # 全局替换
sed -i 's/old/new/g' file.txt        # 直接修改
sed '1,5d' file.txt                  # 删除1-5行
sed -n '2p' file.txt                 # 打印第2行

# grep - 搜索
grep "pattern" file.txt
grep -r "pattern" dir/               # 递归搜索
grep -i "pattern" file.txt           # 忽略大小写
grep -v "pattern" file.txt           # 反向匹配
grep -E "regex" file.txt             # 扩展正则

# 管道组合
cat file.txt | grep "pattern" | awk '{print $2}' | sort

三、进程管理

4. 进程管理

问题：进程管理命令

答案： 核心回答：ps、top、kill 用于进程管理。

代码示例：

# 查看进程
ps aux                          # 所有进程
ps -ef                          # 详细格式
top                              # 实时监控
htop                             # 增强版 top

# 查找进程
ps aux | grep nginx
pgrep -f "nginx"

# 信号与 kill
kill -l                          # 列出信号
kill -9 pid                      # 强制终止
kill -15 pid                     # 优雅终止（SIGTERM）
killall nginx                     # 按名称终止
pkill -f "nginx"                 # 按模式终止

# 后台进程
nohup command &                  # 后台运行
bg                               # 后台任务
fg                               # 前台任务
jobs                             # 任务列表

四、网络管理

5. 网络命令

问题：网络命令

答案： 核心回答：ping、curl、wget、netstat、ss 是常用网络命令。

代码示例：

# 测试连通性
ping -c 4 example.com           # 发4个包
ping -i 0.5 example.com         # 0.5秒间隔

# 下载
curl https://example.com       # 下载页面
curl -O file.txt               # 下载文件
curl -L url                    #跟随重定向
wget url                        # 下载工具
wget -c url                    # 断点续传

# 网络诊断
netstat -tuln                  # 监听端口
netstat -anp | grep 80         # 查找端口占用
ss -tuln                       # 替代 netstat
netstat -i                      # 网卡信息

# curl 高级用法
curl -X POST url -d "data"    # POST 请求
curl -H "Header: value" url   # 自定义头
curl -v url                    # 详细输出

五、磁盘与内存

6. 磁盘与内存

问题：磁盘与内存命令

答案： 核心回答：df、du、free 是查看磁盘和内存的常用命令。

代码示例：

# 磁盘使用
df -h                          # 人类可读格式
df -i                          # 查看 inode
du -sh *                       # 目录大小
du -sh /path/to/dir            # 指定目录

# 内存使用
free -h                        # 人类可读格式
free -m                        # MB 为单位
cat /proc/meminfo              # 详细内存信息

# 磁盘挂载
mount /dev/sdb1 /mnt/usb      # 挂载
umount /mnt/usb                # 卸载
df -T                           # 显示文件系统类型

When you need to run a program with a different set of variables, test a script in a clean environment, or write a shebang line that works across systems, the env command is the right tool. It prints the current environment, sets or removes variables for a single command, and can even start a process with no inherited variables at all.

This guide covers how to use the env command with practical examples for everyday tasks.

env Syntax #

env [OPTIONS] [NAME=VALUE]... [COMMAND [ARGS]]

When called without arguments, env prints every environment variable in the current session, one per line. When followed by NAME=VALUE pairs and a command, it runs that command with the specified variables added or changed without affecting the current shell.

Print All Environment Variables #

The simplest use of env is printing the full environment:

env

SHELL=/bin/bash
USER=john
HOME=/home/john
LANG=en_US.UTF-8
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
TERM=xterm-256color
XDG_SESSION_TYPE=tty
EDITOR=vim

Each line is a KEY=value pair. This is identical to what printenv shows with no arguments. The difference between the two commands becomes clear when you start passing options: printenv is designed for inspecting variables, while env is designed for modifying the environment before launching a program.

Print Variables with NUL Separator #

By default, env separates each variable with a newline character. If variable values contain newlines themselves, the output becomes ambiguous. The -0 (or --null) option ends each entry with a NUL byte instead:

env -0 | tr '\0' '\n' | head -5

This is useful when piping environment data into tools that expect NUL-delimited input, such as xargs with its -0 flag.

Run a Command with Modified Variables #

The most practical feature of env is launching a command with variables changed for that command only. Place NAME=VALUE pairs before the command:

env LANG=C sort unsorted.txt

This runs sort with LANG set to C, which forces byte-order sorting regardless of the system locale. The current shell’s LANG value stays unchanged after the command finishes.

You can set multiple variables at once:

env DB_HOST=localhost DB_PORT=5432 python3 app.py

The application sees DB_HOST and DB_PORT in its environment, but those variables do not persist in your shell session after the process exits.

Run a Command in a Clean Environment #

The -i (or --ignore-environment) option clears the entire inherited environment before running the command. Only the variables you explicitly set on the command line will be present:

env -i bash -c 'env'

PWD=/home/john
SHLVL=1
_=/usr/bin/env

The output shows almost nothing. The shell itself sets a few internal variables (PWD, SHLVL, _), but everything the parent shell normally passes along (PATH, HOME, LANG, USER) is gone.

This is useful for testing whether a script depends on variables it does not set itself. You can combine -i with explicit variables to create a minimal, controlled environment:

env -i HOME=/home/john PATH=/usr/bin:/bin bash -c 'echo $HOME; echo $PATH'

/home/john
/usr/bin:/bin

A bare - (hyphen) works as a shorthand for -i:

env - PATH=/usr/bin bash -c 'echo $PATH'

Unset a Variable for a Command #

The -u (or --unset) option removes a specific variable from the environment before running the command:

env -u EDITOR vim

This launches vim without the EDITOR variable in its environment. Other variables remain untouched. You can unset multiple variables by repeating -u:

env -u LANG -u LC_ALL python3 script.py

The difference from -i is that -u is surgical: it removes only the named variables and leaves everything else in place.

Change Directory Before Running a Command #

The -C (or --chdir) option changes the working directory before executing the command:

env -C /var/log cat syslog | head -3

This is equivalent to running cd /var/log && cat syslog, but without affecting the current shell’s working directory. It is a convenient way to run a command in another directory from within a script or one-liner.

Using env in Shebangs #

One of the most common uses of env is in shebang lines at the top of scripts:

#!/usr/bin/env bash
echo "Hello from Bash"

When the kernel encounters #!/usr/bin/env bash, it runs /usr/bin/env with bash as its argument. env then searches the PATH for the bash executable and runs it. This is more portable than hardcoding #!/bin/bash, because bash is not always located in /bin on every system (for example, on FreeBSD it is typically at /usr/local/bin/bash).

The same pattern works for other interpreters:

#!/usr/bin/env python3

#!/usr/bin/env node

On systems with GNU coreutils 8.30 or later, you can pass arguments to the interpreter using the -S (split string) option:

#!/usr/bin/env -S python3 -u

Without -S, the kernel treats python3 -u as a single argument. The -S option tells env to split the string into separate arguments before executing.

env Options #

• -i, --ignore-environment - Start with an empty environment
• -u NAME, --unset=NAME - Remove NAME from the environment
• -C DIR, --chdir=DIR - Change working directory to DIR before running the command
• -0, --null - End each output line with a NUL byte instead of a newline
• -S STRING, --split-string=STRING - Split STRING into separate arguments (useful in shebangs)
• -v, --debug - Print verbose information for each processing step
• --block-signal=SIG - Block delivery of the specified signal to the command
• --default-signal=SIG - Reset signal handling to the default for the command
• --ignore-signal=SIG - Set signal handling to ignore for the command

Quick Reference #

For a printable quick reference, see the env cheatsheet .

FAQ #

What is the difference between env and printenv?
Both commands print environment variables when called without arguments. The difference is in their purpose: printenv is a read-only inspection tool that can print individual variables by name (printenv HOME). env is designed to modify the environment and run commands. Use printenv when you need to check a value, and env when you need to change the environment for a process.

What is the difference between env and export?
export is a shell built-in that adds a variable to the current shell’s environment permanently (until the session ends or you unset it). env sets variables only for the duration of a single command and does not affect the current shell. If you need a variable to persist for all subsequent commands in your session, use export. If you need a variable set for one command only, use env or the shell’s VAR=value command syntax.

When should I use env -i?
Use env -i when you want to verify that a script or program works without relying on inherited environment variables. It is also useful in security-sensitive contexts where you want to prevent a child process from seeing variables like AWS_SECRET_ACCESS_KEY or database credentials that exist in the parent shell.

Why use #!/usr/bin/env bash instead of #!/bin/bash?
The env-based shebang is more portable. On most Linux distributions, bash lives at /bin/bash, but on other Unix systems (FreeBSD, macOS with Homebrew, NixOS) it may be installed elsewhere. Using #!/usr/bin/env bash searches the PATH for the interpreter, so the script works regardless of where bash is installed.

Conclusion #

The env command gives you fine-grained control over the environment a process sees without touching your current shell session. For a broader look at how environment and shell variables work in Linux, including persistent configuration and the PATH variable, see the guide on how to set and list environment variables .

When a server starts responding slowly or a desktop session feels sluggish, you need to figure out which process is consuming the most CPU or memory. The top command can do this, but its interface is minimal and navigation takes some getting used to. htop is an interactive process viewer that improves on top with color-coded meters, mouse support, and the ability to scroll, search, filter, and kill processes without leaving the viewer.

This guide explains how to install and use htop to monitor system resources and manage processes on Linux.

Installing htop #

htop is available in the default repositories of most Linux distributions but is not always pre-installed.

On Ubuntu, Debian, and Derivatives:

sudo apt install htop

On Fedora, RHEL, and Derivatives:

sudo dnf install htop

Verify the installation by checking the version:

htop --version

htop 3.4.1

htop Syntax #

htop [OPTIONS]

Running htop without arguments opens the interactive process viewer with default settings:

htop

Understanding the Interface #

The htop screen is divided into three areas: a header with system meters, a process list in the center, and a footer with function key shortcuts.

Header Area #

The top section shows system-wide resource usage at a glance:

• CPU bars: one bar per CPU core, color-coded by usage type. Green is normal user processes, red is kernel (system) activity, blue is low-priority (nice) processes, and cyan is virtualization overhead (steal time)
• Memory bar: shows used, buffered, and cached memory as a proportion of total RAM. Green is memory in use by applications, blue is buffers, and yellow is file cache
• Swap bar: shows swap usage. If this bar is consistently full, the system does not have enough physical memory for its workload
• Tasks: total number of processes and threads, with a count of how many are currently running
• Load average: the 1-minute, 5-minute, and 15-minute system load averages
• Uptime: how long the system has been running since the last boot

Process List #

Below the header, each row represents one process. The default columns are:

• PID - process ID
• USER - the owner of the process
• PRI - kernel scheduling priority
• NI - nice value (user-space priority, ranges from -20 to 19)
• VIRT - total virtual memory the process has allocated
• RES - resident memory, the portion of physical RAM the process is actually using
• SHR - shared memory, the portion of RES that is shared with other processes (such as shared libraries)
• S - process state (R running, S sleeping, D uninterruptible sleep, Z zombie, T stopped)
• CPU% - percentage of CPU time the process is using
• MEM% - percentage of physical memory the process is using
• TIME+ - total CPU time consumed since the process started
• Command - the full command line that launched the process

Function Keys #

The bottom bar shows the available actions:

• F1 - open the help screen
• F2 - open the setup menu to customize meters and columns
• F3 - search for a process by name
• F4 - filter the process list to show only matching entries
• F5 - toggle tree view
• F6 - choose a column to sort by
• F7 - decrease the nice value (higher priority) of the selected process
• F8 - increase the nice value (lower priority) of the selected process
• F9 - send a signal to the selected process
• F10 - quit htop

Sorting Processes #

By default, htop sorts processes by CPU usage, so the heaviest processes float to the top. To change the sort column, press F6 and select a column from the list using the arrow keys.

For quick sorting without opening the menu, use these shortcut keys:

• P - sort by CPU%
• M - sort by MEM%
• T - sort by TIME+

Press the same key again to reverse the sort order. This is useful when you want to find the least active processes or the ones that started most recently.

You can also set the initial sort column from the command line:

htop -s PERCENT_MEM

This starts htop with the process list sorted by memory usage, which is handy when you are investigating high memory consumption on a server.

Searching for a Process #

Press F3 (or /) to open the search bar at the bottom of the screen. Type part of the process name and htop will highlight the first matching entry in the process list. Press F3 again to jump to the next match.

The search is incremental, so the highlight updates as you type each character. Press Esc to close the search bar and return to normal navigation.

Filtering Processes #

Press F4 to activate the filter. Unlike search, which jumps between matches, filtering hides all processes that do not match the text you type. Only matching entries remain visible in the list.

This is especially useful on busy systems with hundreds of running processes. For example, typing postgres after pressing F4 reduces the list to only PostgreSQL worker processes and the postmaster, making it much easier to see their combined resource usage.

Press Esc to clear the filter and restore the full process list.

Tree View #

Press F5 to toggle tree view. In this mode, htop groups child processes under their parent and displays the process hierarchy as an indented tree. This makes it straightforward to see which processes were spawned by a service manager, a shell session, or a container runtime.

To start htop in tree view directly from the command line:

htop -t

Tree view combines well with filtering. Press F4, type a service name, and the tree shows only that service and its child processes. For a dedicated look at process hierarchies outside of htop, see the pstree command .

Killing a Process #

To stop a process from within htop, use the arrow keys to highlight it (or search with F3), then press F9. This opens a signal selection menu on the left side of the screen.

The most commonly used signals are:

• 15 SIGTERM - asks the process to shut down gracefully. This is the default and the safest first choice
• 9 SIGKILL - forces the process to terminate immediately. Use this only when SIGTERM does not work, because the process gets no chance to clean up
• 2 SIGINT - the same signal sent by pressing Ctrl+C in a terminal
• 1 SIGHUP - often used to tell a daemon to reload its configuration without restarting

Select the signal with the arrow keys and press Enter to send it. For more detail on process signals and how to send them from the command line, see the kill command guide .

You can also tag multiple processes with Space and then press F9 to send a signal to all of them at once. Press U to untag all processes when you are done.

Changing Process Priority #

You can adjust the scheduling priority (nice value) of a process directly from htop. Select the process and press:

• F7 - decrease the nice value (give the process higher priority)
• F8 - increase the nice value (give the process lower priority)

Nice values range from -20 (highest priority) to 19 (lowest priority). Only root can set negative nice values, so you will need to run htop with sudo to raise a process above normal priority.

This is useful when a background task like a large compilation is consuming too much CPU and you want to lower its priority so that interactive services remain responsive.

Showing Only One User’s Processes #

To limit the process list to a single user, start htop with the -u option:

htop -u www-data

This shows only processes owned by www-data, which is useful when you are debugging a web server or an application service and do not want system processes cluttering the view.

Monitoring Specific Processes #

To watch a known set of processes by their PIDs, use the -p option:

htop -p 1234,5678

The display is restricted to those two processes, but the header meters still show system-wide resource usage. This gives you a focused view while keeping overall load visible at the top.

Customizing the Display #

Press F2 to open the setup screen. From here you can:

• Rearrange the header meters (move CPU bars, swap positions, switch between bar, text, graph, or LED display styles)
• Add or remove columns in the process list
• Change the color scheme
• Toggle display options like showing kernel threads or custom thread names

Changes are saved to ~/.config/htop/htoprc and persist across sessions.

Command-Line Options #

• -d N - set the update interval to N tenths of a second. For example, -d 20 updates every 2 seconds instead of the default 1.5 seconds
• -u USER - show only processes belonging to USER
• -p PID[,PID...] - show only the specified process IDs
• -t - start in tree view
• -s COLUMN - sort by the given column name (use names like PERCENT_CPU, PERCENT_MEM, TIME)
• -C - use monochrome mode (no colors), useful on terminals with limited color support
• -H - highlight new and old processes

Quick Reference #

For a printable quick reference, see the htop cheatsheet .

Troubleshooting #

htop: command not found
htop is not installed by default on every distribution. Install it with your package manager: sudo apt install htop on Debian-based systems or sudo dnf install htop on Fedora and RHEL.

Cannot change process priority (permission denied)
Setting a nice value below 0 requires root privileges. Run htop with sudo to adjust priority for processes owned by other users or to set negative nice values.

CPU bars show unexpected colors
Each color represents a different type of CPU usage. Green is normal user processes, red is kernel activity, blue is low-priority (nice) processes, and cyan is virtualization steal time. Press F1 inside htop to see the full color legend for your version.

Memory bar looks full but the system is responsive
Linux uses free memory for disk cache and buffers. The memory bar in htop distinguishes between application memory (green), buffers (blue), and cache (yellow). Cached memory is released to applications when they need it, so a full-looking bar does not mean the system is out of memory.

Processes appear and disappear quickly
Short-lived processes can start and exit between screen refreshes. Lower the update interval with -d 5 (half a second) to catch fast processes. Keep in mind that a very short interval increases the CPU usage of htop itself.

FAQ #

What is the difference between htop and top?
Both show running processes and system metrics in real time. htop adds color-coded CPU and memory meters, mouse support, horizontal and vertical scrolling, built-in search and filtering, and the ability to kill or renice processes without typing a PID. The top command is pre-installed on virtually every Linux system, while htop may need to be installed separately.

Does htop use more resources than top?
Slightly. htop reads additional process details from /proc, so it uses a bit more CPU and memory than top. On modern hardware the difference is negligible, even on systems with thousands of processes.

What do VIRT, RES, and SHR mean?
VIRT is the total virtual memory the process has mapped, including memory it has allocated but may not be using yet. RES (Resident) is the portion actually held in physical RAM. SHR (Shared) is the subset of RES that is shared with other processes, such as shared libraries loaded by multiple programs.

How do I save my htop configuration?
Press F2 to open the setup screen, make your changes, and press F10 to exit. htop saves the configuration automatically to ~/.config/htop/htoprc.

Can I run htop over SSH?
Yes. htop works in any terminal emulator, including SSH sessions. If you are monitoring a remote server over a long session, consider running htop inside screen or tmux so the session persists if the connection drops.

Conclusion #

htop gives you a clear, interactive view of what is running on your system and the resources each process is consuming. For related tools, see the ps command for snapshot process listings, kill for sending signals from the command line, and pstree for visualizing the process hierarchy.

When you delete a file but the disk space does not come back, or a port appears occupied and you cannot tell what is using it, the lsof command gives you the answer. lsof stands for “list open files.” In Linux, many resources are represented as files, so lsof can show regular files, directories, pipes, sockets, and network connections.

This guide explains how to use lsof to inspect open files, trace network connections, and identify which processes hold resources on your system.

lsof Syntax #

lsof [OPTIONS] [FILE]

When called without arguments, lsof attempts to list every open file visible to the current user. That output is usually thousands of lines long, so in practice you will almost always combine it with a filter or run it with sudo when you need a full system-wide view.

Understanding the Output #

Running lsof without arguments produces output like this:

sudo lsof | head -5

COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
systemd 1 root cwd DIR 8,1 4096 2 /
systemd 1 root rtd DIR 8,1 4096 2 /
nginx 1234 root 6u IPv4 28743 0t0 TCP *:http (LISTEN)
bash 5678 john 1u REG 8,1 102400 789 /home/john/log.txt

Each column tells you something specific:

• COMMAND - the name of the process
• PID - process ID
• USER - the user running the process
• FD - file descriptor (cwd is the current working directory, txt is the program executable, a number like 4u is an open file handle where r means read, w means write, and u means read and write)
• TYPE - type of file (REG for a regular file, DIR for a directory, IPv4/IPv6 for network sockets, unix for Unix domain sockets)
• SIZE/OFF - file size or current offset
• NAME - the file path or network address

Find What Is Using a Port #

The most common use for lsof is finding which process is listening on a given port. For that, use numeric output, limit the search to TCP, and filter to the LISTEN state:

sudo lsof -nP -iTCP:80 -sTCP:LISTEN

COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
nginx 1234 root 6u IPv4 34120 0t0 TCP *:80 (LISTEN)
nginx 1235 www-data 6u IPv4 34120 0t0 TCP *:80 (LISTEN)

The output shows that nginx is listening on port 80. The PID column gives you the process ID if you need to stop or restart it. The -nP options keep addresses and port numbers numeric, which makes the output easier to read in scripts and troubleshooting sessions.

To filter by both protocol and port number, specify the protocol before the port:

sudo lsof -nP -iTCP:443 -sTCP:LISTEN

This is useful when both TCP and UDP services share the same port number and you want to narrow the results to listening TCP sockets only.

List All Network Connections #

To see all open network connections on the system, pass -i without a port:

sudo lsof -i

To narrow the results to a specific protocol, add TCP or UDP:

sudo lsof -i TCP

COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
nginx 1234 root 6u IPv4 34120 0t0 TCP *:http (LISTEN)
sshd 2345 root 3u IPv4 39210 0t0 TCP *:ssh (LISTEN)
curl 5678 john 5u IPv4 56789 0t0 TCP workstation:54321->93.184.216.34:http (ESTABLISHED)

Listening services show an asterisk for the address. Established connections show the remote address and port.

List Files Opened by a Process #

To see all files opened by a specific process, pass the process ID with -p:

sudo lsof -p 1234

To exclude a process instead, prefix the PID with ^:

sudo lsof -p ^1234

You can also filter by process name with -c. This matches any running process whose name starts with the given string:

sudo lsof -c nginx

List Files Opened by a User #

To see all files a particular user has open, use -u followed by the username:

lsof -u john

To see files opened by everyone except that user, prefix the username with ^:

sudo lsof -u ^john

This is useful on multi-user systems when you want to audit what a specific account is accessing.

Find Which Process Has a File Open #

Pass a file path directly to lsof to see which processes currently have it open:

lsof /var/log/nginx/access.log

COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
nginx 1234 root 5w REG 8,1 249856 654321 /var/log/nginx/access.log
nginx 1235 www-data 5w REG 8,1 249856 654321 /var/log/nginx/access.log

This works for any file, including device files, sockets, and named pipes.

List All Open Files in a Directory #

To list all files open within a directory and its subdirectories, use +D:

sudo lsof +D /var/log

For a non-recursive listing (top-level only), use lowercase +d:

sudo lsof +d /var/log

+D is especially useful before unmounting a filesystem. If any process has a file open inside the mount point, umount will refuse to proceed. Running lsof +D /mountpoint tells you exactly which process is blocking it.

Find Deleted Files Still Holding Disk Space #

When you delete a file that a running process still has open, the kernel keeps the data on disk until the process closes the file descriptor or exits. This is a common cause of the “disk is full but I cannot find any large files” problem.

To find these held-open deleted files, use +L1:

sudo lsof +L1

COMMAND PID USER FD TYPE DEVICE SIZE/OFF NLINK NODE NAME
python3 4567 john 3r REG 8,1 2097152 0 456 /tmp/data.bin (deleted)

The NLINK column shows 0, meaning the file has no directory entry left but is still open. Restarting the process listed under COMMAND will release the space. For more ways to find large files on Linux , including files that are still visible on disk, see that dedicated guide.

Get Only Process IDs #

The -t option outputs only process IDs, with no headers or other columns. This is designed for scripting:

sudo lsof -t -iTCP:8080 -sTCP:LISTEN

3456

A common pattern is to stop the process listening on a port:

kill $(sudo lsof -t -iTCP:8080 -sTCP:LISTEN)

Verify the process first with sudo lsof -nP -iTCP:8080 -sTCP:LISTEN before killing it, so you know what you are stopping.

Combining Filters #

By default, lsof treats multiple options as OR logic: the output includes files matching any of the conditions. To switch to AND logic (a result must satisfy all conditions), add -a:

sudo lsof -a -u john -i TCP

Without -a, this command would return all TCP connections on the system plus all files opened by john. With -a, it returns only TCP connections that belong specifically to john.

Quick Reference #

For a printable quick reference, see the lsof cheatsheet .

FAQ #

Why does lsof require sudo?
Without root privileges, lsof can only show files opened by your own processes. Running it with sudo gives you visibility into all processes on the system. Some distributions also restrict access to /proc for non-root users, which limits what lsof can read without elevated permissions.

What is the difference between lsof and ss?
lsof covers the full range of open files: regular files, directories, pipes, devices, and network sockets in a single view. The ss command is purpose-built for network sockets and provides more detail about socket states and statistics. Use lsof when you want to tie a network connection back to a specific file or see everything a process has open. Use ss when you need to inspect socket state in detail.

How do I find which process is using a port?
Run sudo lsof -nP -iTCP:PORT -sTCP:LISTEN, replacing PORT with the number you want to check. The ss command with ss -tlnp is another approach covered in the guide on how to check listening ports .

Can I monitor file access in real time with lsof?
No. lsof takes a snapshot at the moment you run it. For real-time filesystem event monitoring, use inotifywait from the inotify-tools package.

lsof shows a file path ending in (deleted). What does that mean?
The file was removed from the directory while a process still had it open. The data remains on disk until the process releases the file descriptor. This is the cause of the “disk full but no large files visible” problem described in the section above. Use lsof +L1 to list all such files and restart the holding process to free the space.

Conclusion #

lsof is one of the most practical diagnostic tools available on Linux. Whether you are tracking down a port conflict, auditing which files a user has open, or recovering disk space from deleted but held-open files, it gives you a direct view into what every process is accessing at any moment.

For related tools, see the ps command guide for process inspection and the ss command guide for dedicated network socket statistics.

When working with text files, you will often need to remove specific lines, whether it is stripping comments from a configuration file, cleaning up blank lines in log output, or cutting a range of lines from a data dump. The sed stream editor handles all of these cases from the command line, without opening the file in an editor.

sed processes input line by line, applies your commands, and writes the result to standard output. The original file stays untouched unless you explicitly tell sed to edit in place. If you need to find and replace text rather than remove entire lines, see How to Use sed to Find and Replace Strings in Files .

This guide explains how to use the sed delete command (d) with practical examples covering line numbers, patterns, ranges, and regular expressions.

How the Delete Command Works #

The general form of a sed delete expression is:

sed 'ADDRESSd' file

ADDRESS selects which lines to delete, and d is the delete command. When sed encounters a line that matches the address, it removes that line from the output entirely. Any line that does not match the address is printed as usual.

For demonstration purposes, the examples in this guide use the following file:

red
green
blue
yellow
white
black
orange
purple

Delete by Line Number #

The simplest form of delete targets a specific line number. To remove the third line, place 3 before the d command:

sed '3d' colors.txt

red
green
yellow
white
black
orange
purple

Notice that “blue” (which was on line 3) is gone from the output, but the original colors.txt file is unchanged. This is the default behavior of sed, and it gives you a safe way to preview changes before committing them.

Sometimes you need to remove the last line of a file without knowing how many lines it contains. The $ address represents the last line:

sed '$d' colors.txt

red
green
blue
yellow
white
black
orange

Here “purple” (the last line) has been removed from the output.

Delete Multiple Specific Lines #

If you need to remove several individual lines, separate the addresses with a semicolon. The following command deletes lines 2, 5, and 8 in a single pass:

sed '2d;5d;8d' colors.txt

red
blue
yellow
black
orange

The output is missing “green” (line 2), “white” (line 5), and “purple” (line 8). You can list as many addresses as needed this way.

Delete a Range of Lines #

To delete a block of consecutive lines, specify a range with two numbers separated by a comma. The following command removes lines 3 through 6:

sed '3,6d' colors.txt

red
green
orange
purple

Everything from “blue” (line 3) through “black” (line 6) is gone, and the remaining lines print normally.

You can also combine a line number with $ to delete from a given line to the end of the file. This keeps only the first four lines:

sed '5,$d' colors.txt

red
green
blue
yellow

Adding ! after the address inverts the selection, so sed deletes every line that is not in the range. The following command keeps only lines 3 through 5 and removes everything else:

sed '3,5!d' colors.txt

blue
yellow
white

This is a convenient way to extract a slice from a file without piping through head and tail.

Delete Every Nth Line #

GNU sed supports the step address first~step, which matches every Nth line starting from a given position. To delete every even-numbered line (2, 4, 6, …):

sed '0~2d' colors.txt

red
blue
white
orange

The first number is the starting offset (0 means “before the first line”, so the first match is line 2) and the second number is the step. In this case sed deletes lines 2, 4, 6, and 8.

To delete every third line starting from line 3:

sed '3~3d' colors.txt

red
green
yellow
white
orange
purple

Lines 3 (“blue”) and 6 (“black”) are removed. This syntax is specific to GNU sed and is not available in the BSD version shipped with macOS.

Delete Lines Matching a Pattern #

One of the most common uses of sed delete is removing lines that contain a specific string. Wrap the search pattern in forward slashes before the d command:

sed '/blue/d' colors.txt

red
green
yellow
white
black
orange
purple

Every line containing the string “blue” is removed from the output. Keep in mind that this is a substring match, so a pattern like /bl/d would also delete the line “black” because it contains “bl”.

If you want the match to be case-insensitive, add the I flag after d:

sed '/Blue/Id' colors.txt

This removes lines containing “blue”, “Blue”, “BLUE”, or any other case variation.

Delete Lines Not Matching a Pattern #

Adding ! after the pattern address inverts the match, so sed deletes every line that does not contain the pattern. The following command removes all lines that do not have the letter “e”:

sed '/e/!d' colors.txt

red
green
blue
yellow
white
orange
purple

Only “black” (line 6) was removed because it is the only line without an “e”. This works similarly to grep , but the advantage of sed is that you can combine it with other editing commands in the same expression.

Delete a Range Between Two Patterns #

You can use two patterns separated by a comma to define a range. sed starts deleting at the first line that matches the opening pattern and stops after the first line that matches the closing pattern. The following command removes everything from “green” through “white”:

sed '/green/,/white/d' colors.txt

red
black
orange
purple

Both the “green” and “white” lines are included in the deletion, along with “blue” and “yellow” between them.

You can also mix a line number with a pattern. This deletes from line 1 through the first line that contains “blue”:

sed '1,/blue/d' colors.txt

yellow
white
black
orange
purple

This kind of mixed address is useful when you know where the range starts (a fixed line) but not where it ends.

Delete Empty Lines #

Removing blank lines is one of the most common sed tasks. To delete completely empty lines, use the pattern ^$, which matches lines where the beginning and end have nothing between them:

sed '/^$/d' file.txt

This works well for truly empty lines, but it will not catch lines that contain only spaces or tabs. To remove those as well, use the [[:space:]] character class:

sed '/^[[:space:]]*$/d' file.txt

The * quantifier matches zero or more whitespace characters, so this pattern covers both empty lines and lines that appear blank but contain invisible whitespace.

Delete Lines Matching a Regular Expression #

The pattern between the slashes is a regular expression, so you can use anchors, character classes, and quantifiers for more precise matching.

A common example is stripping comment lines from a configuration file. The ^# pattern matches any line that starts with #:

sed '/^#/d' config.txt

To delete lines that end with a semicolon, anchor the pattern to the end of the line with $:

sed '/;$/d' source.txt

You can also match by line length. The following command deletes lines that are shorter than 5 characters. The \{0,4\} quantifier means “between 0 and 4 of any character”:

sed '/^.\{0,4\}$/d' file.txt

If you find the backslash escaping awkward, use extended regular expressions with the -E flag (or -r on older systems). This lets you write the same expression without escaping the braces:

sed -E '/^.{0,4}$/d' file.txt

Combining Delete with Other Commands #

One of the strengths of sed is that you can chain multiple operations in a single expression. For example, the following command first removes comment lines and then replaces “localhost” with “127.0.0.1” in whatever remains:

sed '/^#/d; s/localhost/127.0.0.1/g' config.txt

The commands are separated by a semicolon and execute left to right. If a line is deleted by an earlier command, the later commands never see it, so the replacement only applies to non-comment lines.

Editing Files In Place #

All of the examples above print the modified text to standard output without changing the original file. When you are satisfied with the result, add the -i flag to apply the changes directly:

sed -i '/^$/d' file.txt

On macOS, the BSD version of sed requires an explicit extension argument even if you do not want a backup. Use sed -i '' '/^$/d' file.txt for in-place editing without creating a backup file.

Quick Reference #

For a printable quick reference, see the sed cheatsheet .

FAQ #

How do I delete a line containing a specific word? Use sed '/word/d' file.txt. This removes any line where “word” appears as a substring. If you want to match the whole word only (so that “keyword” is not affected), use word boundaries: sed '/\bword\b/d' file.txt.

Can I delete lines from multiple files at once? Yes. Pass multiple filenames after the expression: sed -i '/pattern/d' file1.txt file2.txt. To process files recursively, combine sed with find: find . -name "*.log" -exec sed -i '/DEBUG/d' {} +.

What is the difference between sed '/pattern/d' and grep -v 'pattern'? Both remove matching lines from the output. The difference is that sed can combine deletion with other editing commands in the same expression and supports in-place editing with -i. If all you need is simple line filtering, grep -v is shorter to type.

How do I delete a range of lines and save the result? You can either redirect the output to a new file (sed '3,6d' file.txt > cleaned.txt) or edit in place with a backup (sed -i.bak '3,6d' file.txt). Do not redirect to the same input file, because the shell will truncate it before sed has a chance to read it.

Conclusion #

The sed delete command gives you a fast way to remove lines by number, pattern, or range without opening a file in an editor. For replacing text within lines rather than removing them, see the companion guide on sed find and replace . If you need to work with individual columns or fields within a line, awk is often the better tool for the job.

git clone copies an existing Git repository into a new directory on your local machine. It sets up tracking branches for each remote branch and creates a remote called origin pointing back to the source.

This guide explains how to use git clone with the most common options and protocols.

Syntax #

The basic syntax of the git clone command is:

git clone [OPTIONS] REPOSITORY [DIRECTORY]

REPOSITORY is the URL or path of the repository to clone. DIRECTORY is optional; if omitted, Git uses the repository name as the directory name.

Clone a Remote Repository #

The most common way to clone a repository is over HTTPS. For example, to clone a GitHub repository:

git clone https://github.com/user/repo.git

This creates a repo directory in the current working directory, initializes a .git directory inside it, and checks out the default branch.

You can also clone over SSH if you have an SSH key configured :

git clone git@github.com:user/repo.git

SSH is generally preferred for repositories you will push to, as it does not require entering credentials each time.

Clone into a Specific Directory #

By default, git clone creates a directory named after the repository. To clone into a different directory, pass the target path as the second argument:

git clone https://github.com/user/repo.git my-project

To clone into the current directory, use . as the target:

git clone https://github.com/user/repo.git .

Clone a Specific Branch #

By default, git clone checks out the default branch (usually main or master). To clone and check out a different branch, use the -b option:

git clone -b develop https://github.com/user/repo.git

The full repository history is still downloaded; only the checked-out branch differs. To limit the download to a single branch, combine -b with --single-branch:

git clone -b develop --single-branch https://github.com/user/repo.git

Shallow Clone #

A shallow clone downloads only a limited number of recent commits rather than the full history. This is useful for speeding up the clone of large repositories when you do not need the full commit history.

To clone with only the latest commit:

git clone --depth 1 https://github.com/user/repo.git

To include the last 10 commits:

git clone --depth 10 https://github.com/user/repo.git

Shallow clones are commonly used in CI/CD pipelines to reduce download time. To convert a shallow clone to a full clone later, run:

git fetch --unshallow

Clone a Local Repository #

git clone also works with local paths. This is useful for creating an isolated copy for testing:

git clone /path/to/local/repo new-copy

Troubleshooting #

Destination directory is not empty
git clone URL . works only when the current directory is empty. If files already exist, clone into a new directory or move the existing files out of the way first.

Authentication failed over HTTPS
Most Git hosting services no longer accept account passwords for Git operations over HTTPS. Use a personal access token or configure a credential manager so Git can authenticate securely.

Permission denied (publickey)
This error usually means your SSH key is missing, not loaded into your SSH agent, or not added to your account on the Git hosting service. Verify your SSH setup before retrying the clone.

Host key verification failed
SSH could not verify the identity of the remote server. Confirm you are connecting to the correct host, then accept or update the host key in ~/.ssh/known_hosts.

Quick Reference #

For a printable quick reference, see the Git cheatsheet .

FAQ #

What is the difference between HTTPS and SSH cloning?
HTTPS cloning works out of the box but prompts for credentials unless you use a credential manager. SSH cloning requires a key pair to be configured but does not prompt for a password on each push or pull.

Does git clone download all branches?
Yes. All remote branches are fetched, but only the default branch is checked out locally. Use git branch -r to list all remote branches, or git checkout branch-name to switch to one.

How do I clone a private repository?
For HTTPS, provide your username and a personal access token when prompted. For SSH, ensure your public key is added to your account on the hosting service.

Can I clone a specific tag instead of a branch?
Yes. Use -b with the tag name: git clone -b v1.0.0 https://github.com/user/repo.git. Git checks out that tag in a detached HEAD state, so create a branch if you plan to make commits.

Conclusion #

git clone is the starting point for working with any existing Git repository. After cloning, you can inspect the commit history with git log , review changes with git diff , and configure your username and email if you have not done so already.

The jobs command is a Bash built-in that lists all background and suspended processes associated with the current shell session. It shows the job ID, state, and the command that started each job.

This article explains how to use the jobs command, what each option does, and how job specifications work for targeting individual jobs.

Syntax #

The general syntax for the jobs command is:

jobs [OPTIONS] [JOB_SPEC...]

When called without arguments, jobs lists all active jobs in the current shell.

Listing Jobs #

To see all background and suspended jobs, run jobs without any arguments:

jobs

If you have two processes (one running and one stopped), the output will look similar to this:

[1]- Stopped vim notes.txt
[2]+ Running ping google.com &

Each line shows:

• The job number in brackets ([1], [2])
• A + or - sign indicating the current and previous job (more on this below)
• The job state (Running, Stopped, Done)
• The command that started the job

To include the process ID (PID) in the output, use the -l option:

jobs -l

[1]- 14205 Stopped vim notes.txt
[2]+ 14230 Running ping google.com &

The PID is useful when you need to send a signal to a process with the kill command.

Job States #

Jobs reported by the jobs command can be in one of these states:

• Running — the process is actively executing in the background.
• Stopped — the process has been suspended, typically by pressing Ctrl+Z.
• Done — the process has finished. This state appears once and is then cleared from the list.
• Terminated — the process was killed by a signal.

When a background job finishes, the shell displays its Done status the next time you press Enter or run a command.

Job Specifications #

Job specifications (job specs) let you target a specific job when using commands like fg, bg, kill , or disown. They always start with a percent sign (%):

• %1, %2, … — refer to a job by its number.
• %% or %+ — the current job (the most recently backgrounded or suspended job, marked with +).
• %- — the previous job (marked with -).
• %string — the job whose command starts with string. For example, %ping matches a job started with ping google.com.
• %?string — the job whose command contains string anywhere. For example, %?google also matches ping google.com.

Here is a practical example. Start two background jobs:

sleep 300 &
ping -c 100 google.com > /dev/null &

Now list them:

jobs

[1]- Running sleep 300 &
[2]+ Running ping -c 100 google.com > /dev/null &

You can bring the sleep job to the foreground by its number:

fg %1

Or by the command prefix:

fg %sleep

Both are equivalent and bring job [1] to the foreground.

Options #

The jobs command accepts the following options:

• -l — List jobs with their process IDs in addition to the normal output.
• -p — Print only the PID of each job’s process group leader. This is useful for scripting.
• -r — List only running jobs.
• -s — List only stopped (suspended) jobs.
• -n — Show only jobs whose status has changed since the last notification.

To show only running jobs:

jobs -r

To get just the PIDs of all jobs:

jobs -p

14205
14230

Using jobs in Interactive Shells #

The jobs command is primarily useful in an interactive shell where job control is enabled. In a regular shell script, job control is usually off, so jobs may return no output even when background processes exist.

If you need to manage background work in a script, track process IDs with $! and use wait with the PID instead of a job spec:

# Start a background task
long_task &
task_pid=$!

# Poll until it finishes
while kill -0 "$task_pid" 2>/dev/null; do
 echo "Task is still running..."
 sleep 5
done

echo "Task complete."

To wait for several background tasks, store their PIDs and pass them to wait:

task_a &
pid_a=$!

task_b &
pid_b=$!

task_c &
pid_c=$!

wait "$pid_a" "$pid_b" "$pid_c"
echo "All tasks complete."

In an interactive shell, you can still wait for a job by its job spec:

wait %1

Quick Reference #

FAQ #

What is the difference between jobs and ps?
jobs shows only the processes started from the current shell session. The ps command lists all processes running on the system, regardless of which shell started them.

Why does jobs show nothing even though processes are running?
jobs only tracks processes started from the current shell. If you started a process in a different terminal or via a system service, it will not appear in jobs. Use ps aux to find it instead.

How do I stop a background job?
Use kill %N where N is the job number. For example, kill %1 sends SIGTERM to job 1. If the job does not stop, use kill -9 %1 to force-terminate it.

What do the + and - signs mean in jobs output?
The + marks the current job, the one that fg and bg will act on by default. The - marks the previous job. When the current job finishes, the previous job becomes the new current job.

How do I keep a background job running after closing the terminal?
Use nohup before the command, or disown after backgrounding it. For long-running interactive sessions, consider Screen or Tmux .

Conclusion #

The jobs command lists all background and suspended processes in the current shell session. Use it together with fg, bg, and kill to control jobs interactively. For a broader guide on running and managing background processes, see How to Run Linux Commands in the Background .

Every change in a Git repository can be inspected before it is staged or committed. The git diff command shows the exact lines that were added, removed, or modified — between your working directory, the staging area, and any two commits or branches.

This guide explains how to use git diff to review changes at every stage of your workflow.

Basic Usage #

Run git diff with no arguments to see all unstaged changes — differences between your working directory and the staging area:

git diff

diff --git a/app.py b/app.py
index 3b1a2c4..7d8e9f0 100644
--- a/app.py
+++ b/app.py
@@ -10,6 +10,7 @@ def main():
print("Starting app")
+ print("Debug mode enabled")
run()

Lines starting with + were added. Lines starting with - were removed. Lines with no prefix are context — unchanged lines shown for reference.

If nothing is shown, all changes are already staged or there are no changes at all.

Staged Changes #

To see changes that are staged and ready to commit, use --staged (or its synonym --cached):

git diff --staged

This compares the staging area against the last commit. It shows exactly what will go into the next commit.

git diff --cached

Both flags are equivalent. Use whichever you prefer.

Comparing Commits #

Pass two commit hashes to compare them directly:

git diff abc1234 def5678

To compare a commit against its parent, use the ^ suffix:

git diff HEAD^ HEAD

HEAD refers to the latest commit. HEAD^ is one commit before it. You can go further back with HEAD~2, HEAD~3, and so on.

To see what changed in the last commit:

git diff HEAD^ HEAD

Comparing Branches #

Use the same syntax to compare two branches:

git diff main feature-branch

This shows all differences between the tips of the two branches.

To see only what a branch adds relative to main — excluding changes already in main — use the three-dot notation:

git diff main...feature-branch

The three-dot form finds the common ancestor of both branches and diffs from there to the tip of feature-branch. This is the most useful form for reviewing a pull request before merging.

Comparing a Specific File #

To limit the diff to a single file, pass the path after --:

git diff -- path/to/file.py

The -- separator tells Git the argument is a file path, not a branch name. Combine it with commit references to compare a file across commits:

git diff HEAD~3 HEAD -- path/to/file.py

Summary with –stat #

To see a summary of which files changed and how many lines were added or removed — without the full diff — use --stat:

git diff --stat

 app.py | 3 +++
config.yml | 1 -
2 files changed, 3 insertions(+), 1 deletion(-)

This is useful for a quick overview before reviewing the full diff.

Word-Level Diff #

By default, git diff highlights changed lines. To highlight only the changed words within a line, use --word-diff:

git diff --word-diff

@@ -10,6 +10,6 @@ def main():
print("[-Starting-]{+Running+} app")

Removed words appear in [-brackets-] and added words in {+braces+}. This is especially useful for prose or configuration files where only part of a line changes.

Ignoring Whitespace #

To ignore whitespace-only changes, use -w:

git diff -w

Use -b to ignore changes in the amount of whitespace (but not all whitespace):

git diff -b

These options are useful when reviewing files that have been reformatted or indented differently.

Quick Reference #

For a printable quick reference, see the Git cheatsheet .

FAQ #

What is the difference between git diff and git diff --staged?
git diff shows changes in your working directory that have not been staged yet. git diff --staged shows changes that have been staged with git add and are ready to commit. To see all changes — staged and unstaged combined — use git diff HEAD.

What does the three-dot ... notation do in git diff?
git diff main...feature finds the common ancestor of main and feature and shows the diff from that ancestor to the tip of feature. This isolates the changes that the feature branch introduces, ignoring any new commits in main since the branch was created. In git diff, the two-dot form is just another way to name the two revision endpoints, so git diff main..feature is effectively the same as git diff main feature.

How do I see only the file names that changed, not the full diff?
Use git diff --name-only. To include the change status (modified, added, deleted), use git diff --name-status instead.

How do I compare my local branch against the remote?
Fetch first to update remote-tracking refs, then diff against the updated remote branch. To see what your current branch changes relative to origin/main, use git fetch && git diff origin/main...HEAD. If you want a direct endpoint comparison instead, use git fetch && git diff origin/main HEAD.

Can I use git diff to generate a patch file?
Yes. Redirect the output to a file: git diff > changes.patch. Apply it on another machine with git apply changes.patch.

Conclusion #

git diff is the primary tool for reviewing changes before you stage or commit them. Use git diff for unstaged work, git diff --staged before committing, and git diff main...feature to review a branch before merging. For a history of committed changes, see the git log guide .

Every commit in a Git repository is recorded in the project history. The git log command lets you browse that history — showing who made each change, when, and why. It is one of the most frequently used Git commands and one of the most flexible.

This guide explains how to use git log to view, filter, and format commit history.

Basic Usage #

Run git log with no arguments to see the full commit history of the current branch, starting from the most recent commit:

git log

commit a3f1d2e4b5c6789012345678901234567890abcd
Author: Jane Smith <jane@example.com>
Date: Mon Mar 10 14:22:31 2026 +0100
Add user authentication module
commit 7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c
Author: John Doe <john@example.com>
Date: Fri Mar 7 09:15:04 2026 +0100
Fix login form validation

Each entry shows the full commit hash, author name and email, date, and commit message. Press q to exit the log view.

Compact Output with –oneline #

The default output is verbose. Use --oneline to show one commit per line — the abbreviated hash and the subject line only:

git log --oneline

a3f1d2e Add user authentication module
7b8c9d0 Fix login form validation
c1d2e3f Update README with setup instructions

This is useful for a quick overview of recent work.

Limiting the Number of Commits #

To show only the last N commits, pass -n followed by the number:

git log -n 5

You can also write it without the space:

git log -5

Filtering by Author #

Use --author to show only commits by a specific person. The value is matched as a substring against the author name or email:

git log --author="Jane"

To match multiple authors, pass --author more than once:

git log --author="Jane" --author="John"

Filtering by Date #

Use --since and --until to limit commits to a date range. These options accept a variety of formats:

git log --since="2 weeks ago"
git log --since="2026-03-01" --until="2026-03-15"

Searching Commit Messages #

Use --grep to find commits whose message contains a keyword:

git log --grep="authentication"

The search is case-sensitive by default. Add -i to make it case-insensitive:

git log -i --grep="fix"

Viewing Changed Files #

To see a summary of which files were changed in each commit without the full diff, use --stat:

git log --stat

commit a3f1d2e4b5c6789012345678901234567890abcd
Author: Jane Smith <jane@example.com>
Date: Mon Mar 10 14:22:31 2026 +0100
Add user authentication module
src/auth.py | 84 ++++++++++++++++++++++++++++++++++++++++++++++++
src/models.py | 12 +++++++
tests/test_auth.py | 45 +++++++++++++++++
3 files changed, 141 insertions(+)

To see the full diff for each commit, use -p (or --patch):

git log -p

Combine with -n to limit the output:

git log -p -3

Viewing History of a Specific File #

To see only the commits that touched a particular file, pass the file path after --:

git log -- path/to/file.py

The -- separator tells Git that what follows is a path, not a branch name. Add -p to see the exact changes made to that file in each commit:

git log -p -- path/to/file.py

Branch and Graph View #

To visualize how branches diverge and merge, use --graph:

git log --oneline --graph

* a3f1d2e Add user authentication module
* 7b8c9d0 Fix login form validation
| * 3e4f5a6 WIP: dark mode toggle
|/
* c1d2e3f Update README with setup instructions

Add --all to include all branches, not just the current one:

git log --oneline --graph --all

This gives a full picture of the repository’s branch and merge history.

Comparing Two Branches #

To see commits that are in one branch but not another, use the .. notation:

git log main..feature-branch

This shows commits reachable from feature-branch that are not yet in main — useful for reviewing what a branch adds before merging.

Custom Output Format #

Use --pretty=format: to define exactly what each log line shows. Some useful placeholders:

• %h — abbreviated commit hash
• %an — author name
• %ar — author date, relative
• %s — subject (first line of commit message)

For example:

git log --pretty=format:"%h %an %ar %s"

a3f1d2e Jane Smith 5 days ago Add user authentication module
7b8c9d0 John Doe 8 days ago Fix login form validation

Excluding Merge Commits #

To hide merge commits and see only substantive changes, use --no-merges:

git log --no-merges --oneline

Quick Reference #

For a printable quick reference, see the Git cheatsheet .

FAQ #

How do I search for a commit that changed a specific piece of code?
Use -S (the “pickaxe” option) to find commits that added or removed a specific string: git log -S "function_name". For regex patterns, use -G "pattern" instead.

How do I see who last changed each line of a file?
Use git blame path/to/file. It annotates every line with the commit hash, author, and date of the last change.

What is the difference between git log and git reflog?
git log shows the commit history of the current branch. git reflog shows every movement of HEAD — including commits that were reset, rebased, or are no longer reachable from any branch. It is the main recovery tool if you lose commits accidentally.

How do I find a commit by its message?
Use git log --grep="search term". For case-insensitive search add -i. If you need to search the full commit message body as well as the subject, add --all-match only when combining multiple --grep patterns, or use git log --grep="search term" --format=full to inspect matching commits more closely. Use -E only when you need extended regular expressions in the grep pattern.

How do I show a single commit in full detail?
Use git show <hash>. It prints the commit metadata and the full diff. To show just the files changed without the diff, use git show --stat <hash>.

Conclusion #

git log is the primary tool for understanding a project’s history. Start with --oneline for a quick overview, use --graph --all to visualize branches, and combine --author, --since, and --grep to zero in on specific changes. For undoing commits found in the log, see the git revert guide or how to undo the last commit .

When you are in the middle of a feature and need to switch branches to fix a bug or review someone else’s work, you have a problem: your changes are not ready to commit, but you cannot switch branches with a dirty working tree. git stash solves this by saving your uncommitted changes to a temporary stack so you can restore them later.

This guide explains how to use git stash to save, list, apply, and delete stashed changes.

Basic Usage #

The simplest form saves all modifications to tracked files and reverts the working tree to match the last commit:

git stash

Saved working directory and index state WIP on main: abc1234 Add login page

Your working tree is now clean. You can switch branches, pull updates, or apply a hotfix. When you are ready to return to your work, restore the stash.

By default, git stash saves both staged and unstaged changes to tracked files. It does not save untracked or ignored files unless you explicitly include them (see below).

Stashing with a Message #

A plain git stash entry shows the branch and last commit message, which becomes hard to read when you have multiple stashes. Use -m to attach a descriptive label:

git stash push -m "WIP: user authentication form"

This makes it easy to identify the right stash when you list them later.

Listing Stashes #

To see all saved stashes, run:

git stash list

stash@{0}: On main: WIP: user authentication form
stash@{1}: WIP on main: abc1234 Add login page

Stashes are indexed from newest (stash@{0}) to oldest. The index is used when you want to apply or drop a specific stash.

To inspect the contents of a stash before applying it, use git stash show:

git stash show stash@{0}

Add -p to see the full diff:

git stash show -p stash@{0}

Applying Stashes #

There are two ways to restore a stash.

git stash pop applies the most recent stash and removes it from the stash list:

git stash pop

git stash apply applies a stash but keeps it in the list so you can apply it again or to another branch:

git stash apply

To apply a specific stash by index, pass the stash reference:

git stash apply stash@{1}

If applying the stash causes conflicts, resolve them the same way you would resolve a merge conflict, then stage the resolved files.

Stashing Untracked and Ignored Files #

By default, git stash only saves changes to files that Git already tracks. New files you have not yet staged are left behind.

Use -u (or --include-untracked) to include untracked files:

git stash -u

To include both untracked and ignored files — for example, generated build artifacts or local config files — use -a (or --all):

git stash -a

Partial Stash #

If you only want to stash some of your changes and leave others in the working tree, use the -p (or --patch) flag to interactively select which hunks to stash:

git stash -p

Git will step through each changed hunk and ask whether to stash it. Type y to stash the hunk, n to leave it, or ? for a full list of options.

Creating a Branch from a Stash #

If you have been working on a stash for a while and the branch has diverged enough to cause conflicts on apply, you can create a new branch from the stash directly:

git stash branch new-branch-name

This creates a new branch, checks it out at the commit where the stash was originally made, applies the stash, and drops it from the list if it applied cleanly. It is the safest way to resume stashed work that has grown out of sync with the base branch.

Deleting Stashes #

To remove a specific stash once you no longer need it:

git stash drop stash@{0}

To delete all stashes at once:

git stash clear

Use clear with care — there is no undo.

Quick Reference #

For a printable quick reference, see the Git cheatsheet .

FAQ #

What is the difference between git stash pop and git stash apply?
pop applies the stash and removes it from the stash list. apply restores the changes but keeps the stash entry so you can apply it again — for example, to multiple branches. Use pop for normal day-to-day use and apply when you need to reuse the stash.

Does git stash save untracked files?
No, not by default. Run git stash -u to include untracked files, or git stash -a to also include files that match your .gitignore patterns.

Can I stash only specific files?
Yes. In modern Git, you can pass pathspecs to git stash push, for example: git stash push -m "label" -- path/to/file. If you need a more portable workflow, use git stash -p to interactively select which hunks to stash.

How do I recover a dropped stash?
If you accidentally ran git stash drop or git stash clear, the underlying commit may still exist for a while. Run git fsck --no-reflogs | grep "dangling commit" to list unreachable commits, then git show <hash> to inspect them. If you find the right stash commit, you can recreate it with git stash store -m "recovered stash" <hash> and then apply it normally.

Can I apply a stash to a different branch?
Yes. Switch to the target branch with git switch branch-name, then run git stash apply stash@{0}. If there are no conflicts, the changes are applied cleanly. If the branches have diverged significantly, consider git stash branch to create a fresh branch from the stash instead.

Conclusion #

git stash is the cleanest way to set aside incomplete work without creating a throwaway commit. Use git stash push -m to keep your stash list readable, prefer pop for one-time restores, and use git stash branch when applying becomes messy. For a broader overview of Git workflows, see the Git cheatsheet or the git revert guide .

systemd is the init system used by most modern Linux distributions, including Ubuntu, Debian, Fedora, and RHEL. It manages system processes, handles service dependencies, and starts services automatically at boot.

A systemd service file — also called a unit file — tells systemd how to start, stop, and manage a process. This guide explains how to create a systemd service file, install it on the system, and manage it with systemctl.

Quick Reference #

Understanding systemd Unit Files #

Service files are plain text files with an .service extension. They are stored in one of two locations:

• /etc/systemd/system/ — system-wide services, managed by root. Files here take priority over package-installed units.
• /usr/lib/systemd/system/ or /lib/systemd/system/ — units installed by packages, depending on the distribution. Do not edit these directly; copy them to /etc/systemd/system/ to override.

A service file is divided into three sections:

• [Unit] — describes the service and declares dependencies.
• [Service] — defines how to start, stop, and run the process.
• [Install] — controls how and when the service is enabled.

Creating a Simple Service File #

In this example, we will create a service that runs a custom Bash script. First, create the script you want to run:

sudo nano /usr/local/bin/myapp.sh

Add the following content to the script:

#!/bin/bash
echo "myapp started" >> /var/log/myapp.log
# your application logic here
exec /usr/local/bin/myapp

Make the script executable:

sudo chmod +x /usr/local/bin/myapp.sh

Now create the service file:

sudo nano /etc/systemd/system/myapp.service

Add the following content:

[Unit]
Description=My Custom Application
After=network.target

[Service]
Type=simple
ExecStart=/usr/local/bin/myapp.sh
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

After saving the file, reload systemd to pick up the new unit:

sudo systemctl daemon-reload

Enable and start the service:

sudo systemctl enable --now myapp

Check that it is running:

sudo systemctl status myapp

● myapp.service - My Custom Application
Loaded: loaded (/etc/systemd/system/myapp.service; enabled; vendor preset: enabled)
Active: active (running) since Mon 2026-03-10 09:00:00 CET; 2s ago
Main PID: 1234 (myapp.sh)
Tasks: 1 (limit: 4915)
CGroup: /system.slice/myapp.service
└─1234 /bin/bash /usr/local/bin/myapp.sh

Unit File Sections Explained #

[Unit] Section #

The [Unit] section contains metadata and dependency declarations.

Common directives:

• Description= — a short human-readable name shown in systemctl status output.
• After= — start this service only after the listed units are active. Does not create a dependency; use Requires= for hard dependencies.
• Requires= — this service requires the listed units. If they fail, this service fails too.
• Wants= — like Requires=, but the service still starts even if the listed units fail.
• Documentation= — a URL or man page reference for the service.

[Service] Section #

The [Service] section defines the process and how systemd manages it.

Common directives:

• Type= — the startup type. See Service Types below.
• ExecStart= — the command to run when the service starts. Must be an absolute path.
• ExecStop= — the command to run when the service stops. If omitted, systemd sends SIGTERM.
• ExecReload= — the command to reload the service configuration without restarting.
• Restart= — when to restart automatically. See Restart Policies below.
• RestartSec= — how many seconds to wait before restarting. Default is 100ms.
• User= — run the process as this user instead of root.
• Group= — run the process as this group.
• WorkingDirectory= — set the working directory for the process.
• Environment= — set environment variables: Environment="KEY=value".
• EnvironmentFile= — read environment variables from a file.

[Install] Section #

The [Install] section controls how the service is enabled.

• WantedBy=multi-user.target — the most common value. Enables the service for normal multi-user (non-graphical) boot.
• WantedBy=graphical.target — use this if the service requires a graphical environment.

Service Types #

The Type= directive tells systemd how the process behaves at startup.

For most custom scripts and applications, Type=simple is the right choice.

Restart Policies #

The Restart= directive controls when systemd automatically restarts the service.

For long-running services, Restart=on-failure is the most common choice. Use Restart=always for services that must stay running under all circumstances.

Running a Service as a Non-Root User #

Running services as root is a security risk. Use the User= and Group= directives to run the service as a dedicated user:

[Unit]
Description=My Custom Application
After=network.target

[Service]
Type=simple
User=myappuser
Group=myappuser
ExecStart=/usr/local/bin/myapp
Restart=on-failure
WorkingDirectory=/opt/myapp
Environment="NODE_ENV=production"

[Install]
WantedBy=multi-user.target

Create the system user before enabling the service:

sudo useradd -r -s /usr/sbin/nologin myappuser

Troubleshooting #

Service fails to start — “Failed to start myapp.service”
Check the logs with journalctl : sudo journalctl -u myapp --since "5 minutes ago". The output shows the exact error message from the process.

Changes to the service file have no effect
You must run sudo systemctl daemon-reload after every edit to the unit file. systemd reads the file at reload time, not at start time.

“ExecStart= must be an absolute path”
The ExecStart= value must start with /. Use the full path to the binary — for example /usr/bin/python3 not python3. Use which python3 to find the absolute path.

Service starts but immediately exits
The process may be crashing on startup. Check sudo journalctl -u myapp -n 50 for error output. If Type=simple, make sure ExecStart= runs the process in the foreground — not a script that launches a background process and exits.

Service does not start at boot despite being enabled
Confirm the [Install] section has a valid WantedBy= target and that systemctl enable was run after daemon-reload. Check with systemctl is-enabled myapp.

FAQ #

Where should I put my service file?
Put custom service files in /etc/systemd/system/. Files there take priority over package-installed units in /usr/lib/systemd/system/ and persist across package upgrades.

What is the difference between enable and start?
systemctl start starts the service immediately for the current session only. systemctl enable creates a symlink so the service starts automatically at boot. To do both at once, use systemctl enable --now myservice.

How do I view logs for my service?
Use sudo journalctl -u myservice to see all logs. Add -f to follow live output, or --since "1 hour ago" to limit the time range. See the journalctl guide for full usage.

Can I run a service as a regular user without root?
Yes, using user-level systemd units stored in ~/.config/systemd/user/. Manage them with systemctl --user enable myservice. They run when the user logs in and stop when they log out (unless lingering is enabled with loginctl enable-linger username).

How do I reload a service after changing its configuration?
If the service supports it, use sudo systemctl reload myservice — this sends SIGHUP or runs ExecReload= without restarting the process. Otherwise, use sudo systemctl restart myservice.

Conclusion #

Creating a systemd service file gives you full control over how and when your process runs — including automatic restarts, boot integration, and user isolation. Once the file is in place, use systemctl enable --now to activate it and journalctl -u to monitor it. For scheduling tasks that run once at a set time rather than continuously, consider cron jobs as an alternative.

ss is a command-line utility for displaying socket statistics on Linux. It is the modern replacement for the deprecated netstat command and is faster, more detailed, and available by default on all current Linux distributions.

This guide explains how to use ss to list open sockets, filter results by protocol and port, and identify which process is using a given connection.

ss Syntax #

ss [OPTIONS] [FILTER]

When invoked without options, ss displays all non-listening sockets that have an established connection.

List All Sockets #

To list all sockets regardless of state, use the -a option:

ss -a

The output includes columns for the socket type (Netid), state, receive and send queue sizes, local address and port, and peer address and port:

Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port
tcp ESTAB 0 0 192.168.1.10:ssh 192.168.1.5:52710
tcp LISTEN 0 128 0.0.0.0:http 0.0.0.0:*
udp UNCONN 0 0 0.0.0.0:bootpc 0.0.0.0:*

Filter by Socket Type #

TCP Sockets (-t) #

To list only TCP sockets:

ss -t

To include listening TCP sockets as well, combine with -a:

ss -ta

UDP Sockets (-u) #

To list only UDP sockets:

ss -ua

Unix Domain Sockets (-x) #

To list Unix domain sockets used for inter-process communication:

ss -xa

Show Listening Sockets #

The -l option shows only sockets that are in the listening state:

ss -tl

The most commonly used combination is -tulpn, which shows all TCP and UDP listening sockets with process names and numeric addresses:

ss -tulpn

Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
tcp LISTEN 0 128 0.0.0.0:22 0.0.0.0:* users:(("sshd",pid=1234,fd=3))
tcp LISTEN 0 511 0.0.0.0:80 0.0.0.0:* users:(("nginx",pid=5678,fd=6))
udp UNCONN 0 0 0.0.0.0:68 0.0.0.0:* users:(("dhclient",pid=910,fd=6))

Each option in the combination does the following:

• -t — show TCP sockets
• -u — show UDP sockets
• -l — show listening sockets only
• -p — show the process name and PID
• -n — show numeric addresses and ports instead of resolving hostnames and service names

Show Process Information #

The -p option adds the process name and PID to the output. This requires root privileges to see processes owned by other users:

sudo ss -tp

State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
ESTAB 0 0 192.168.1.10:ssh 192.168.1.5:52710 users:(("sshd",pid=2341,fd=5))

Use Numeric Output #

By default, ss resolves port numbers to service names (for example, port 22 becomes ssh). The -n option disables this and shows raw port numbers:

ss -tn

This is useful when you need to match exact port numbers in scripts or when name resolution is slow.

Filter by Port #

To find which process is using a specific port, filter by destination or source port. For example, to list all sockets using port 80:

ss -tulpn | grep :80

You can also use the built-in filter syntax:

ss -tnp 'dport = :443'

To filter by source port:

ss -tnp 'sport = :22'

Filter by Connection State #

ss supports filtering by connection state. Common states include ESTABLISHED, LISTEN, TIME-WAIT, and CLOSE-WAIT.

To show only established TCP connections:

ss -tn state ESTABLISHED

To show only sockets in the TIME-WAIT state:

ss -tn state TIME-WAIT

Filter by Address #

To show sockets connected to or from a specific IP address:

ss -tn dst 192.168.1.5

To filter by source address:

ss -tn src 192.168.1.10

You can combine address and port filters:

ss -tnp dst 192.168.1.5 dport = :22

Show IPv4 or IPv6 Only #

To restrict output to IPv4 sockets, use -4:

ss -tln -4

To show only IPv6 sockets, use -6:

ss -tln -6

Show Summary Statistics #

The -s option prints a summary of socket counts by type and state without listing individual sockets:

ss -s

Total: 312
TCP: 14 (estab 4, closed 3, orphaned 0, timewait 3)
Transport Total IP IPv6
RAW 1 0 1
UDP 6 4 2
TCP 11 7 4
INET 18 11 7
FRAG 0 0 0

This is useful for a quick overview of the network state on a busy server.

Practical Examples #

The following examples cover common diagnostics you will use together with tools like ip , ifconfig , and check listening ports .

Find which process is listening on port 8080:

sudo ss -tlpn sport = :8080

List all established SSH connections to your server:

ss -tn state ESTABLISHED '( dport = :22 or sport = :22 )'

Show all connections to a remote host:

ss -tn dst 203.0.113.10

Count established TCP connections:

ss -tn state ESTABLISHED | tail -n +2 | wc -l

Quick Reference #

Troubleshooting #

ss -p does not show process names
Process information for sockets owned by other users requires elevated privileges. Use sudo ss -tp or sudo ss -tulpn.

Filters return no results
Use quoted filter expressions such as ss -tn 'dport = :443', and verify whether you should filter by sport or dport.

Service names hide numeric ports
If output shows service names (ssh, http) instead of port numbers, add -n to keep numeric ports and avoid lookup ambiguity.

Output is too broad on busy servers
Start with protocol and state filters (-t, -u, state ESTABLISHED) and then add address or port filters to narrow results.

You need command-level context, not only sockets
Use ss with ps or pgrep when you need additional process detail.

FAQ #

What is the difference between ss and netstat?
ss is the modern replacement for netstat. It reads directly from kernel socket structures, making it significantly faster on systems with many connections. netstat is part of the net-tools package, which is deprecated and not installed by default on most current distributions.

Why do I need sudo with ss -p?
Without root privileges, ss can only show process information for sockets owned by your own user. To see process names and PIDs for all sockets, run ss with sudo.

What does Recv-Q and Send-Q mean in the output?
Recv-Q is the number of bytes received but not yet read by the application. Send-Q is the number of bytes sent but not yet acknowledged by the remote host. Non-zero values on a listening socket or consistently high values can indicate a performance issue.

How do I find which process is using a specific port?
Run sudo ss -tulpn | grep :<port>. The -p flag adds process information and -n keeps port numbers numeric so the grep match is reliable.

Conclusion #

ss is the standard tool for inspecting socket connections on modern Linux systems. The -tulpn combination covers most day-to-day needs, while the state and address filters make it easy to narrow results on busy servers. For related network diagnostics, see the ip and ifconfig command guides, or check listening ports for a broader overview.

uniq is a command-line utility that filters adjacent duplicate lines from sorted input and writes the result to standard output. It is most commonly used together with sort to remove or count duplicates across an entire file.

This guide explains how to use the uniq command with practical examples.

uniq Command Syntax #

The syntax for the uniq command is as follows:

uniq [OPTIONS] [INPUT [OUTPUT]]

If no input file is specified, uniq reads from standard input. The optional OUTPUT argument redirects the result to a file instead of standard output.

Removing Duplicate Lines #

By default, uniq removes adjacent duplicate lines, keeping one copy of each. Because it only compares consecutive lines, the input must be sorted first — otherwise only back-to-back duplicates are removed.

Given a file with repeated entries:

apple
apple
banana
cherry
banana
cherry
cherry

Running uniq on the unsorted file removes only the back-to-back duplicates (apple apple and cherry cherry), but leaves the second banana and the second cherry intact:

uniq fruits.txt

apple
banana
cherry
banana
cherry

To remove all duplicates regardless of position, sort the file first:

sort fruits.txt | uniq

apple
banana
cherry

Counting Occurrences #

To prefix each output line with the number of times it appears, use the -c (--count) option:

sort fruits.txt | uniq -c

 2 apple
2 banana
3 cherry

The count and the line are separated by whitespace. This is especially useful for finding the most frequent lines in a file. To rank them from most to least common, pipe the output back to sort:

sort fruits.txt | uniq -c | sort -rn

 3 cherry
2 banana
2 apple

Showing Only Duplicate Lines #

To print only lines that appear more than once (one copy per group), use the -d (--repeated) option:

sort fruits.txt | uniq -d

apple
banana
cherry

To print every instance of a repeated line rather than just one, use -D:

sort fruits.txt | uniq -D

apple
apple
banana
banana
cherry
cherry
cherry

Showing Only Unique Lines #

To print only lines that appear exactly once (no duplicates), use the -u (--unique) option:

sort fruits.txt | uniq -u

If every line appears more than once, the output is empty. In the example above, all three fruits are duplicated, so nothing is printed.

Ignoring Case #

By default, uniq comparisons are case-sensitive, so Apple and apple are treated as different lines. To compare lines case-insensitively, use the -i (--ignore-case) option:

sort -f file.txt | uniq -i

Skipping Fields and Characters #

uniq can be told to skip leading fields or characters before comparing lines.

To skip the first N whitespace-separated fields, use -f N (--skip-fields=N). This is useful when lines share a common prefix (such as a timestamp) that should not be part of the comparison:

2026-01-01 ERROR disk full
2026-01-02 ERROR disk full
2026-01-03 WARNING low memory

uniq -f 1 log.txt

2026-01-01 ERROR disk full
2026-01-03 WARNING low memory

The first field (the date) is skipped, so the two ERROR disk full lines are treated as duplicates.

To skip the first N characters instead of fields, use -s N (--skip-chars=N). To limit the comparison to the first N characters per line, use -w N (--check-chars=N).

Combining uniq with Other Commands #

uniq works well in pipelines with grep , cut , sort , and wc .

To count the number of unique lines in a file:

sort file.txt | uniq | wc -l

To find the top 10 most common words in a text file:

grep -Eo '[[:alnum:]]+' file.txt | sort | uniq -c | sort -rn | head -10

To list unique IP addresses from an access log:

awk '{print $1}' /var/log/nginx/access.log | sort | uniq

To find lines that appear in one file but not another (using -u against merged sorted files):

sort file1.txt file2.txt | uniq -u

Quick Reference #

Troubleshooting #

Duplicates are not removed uniq only removes adjacent duplicate lines. If the file is not sorted, non-consecutive duplicates are not detected. Always sort the input first: sort file.txt | uniq.

-c output has inconsistent spacing The count is right-aligned and padded with spaces. If you need to process the output further, use awk to normalize spacing while preserving the full line text: sort file.txt | uniq -c | awk '{count=$1; $1=\"\"; sub(/^ +/, \"\"); print count, $0}'.

Case variants are treated as different lines Use the -i option to compare case-insensitively. Also sort with -f so that case-insensitive duplicates are adjacent before uniq processes them: sort -f file.txt | uniq -i.

FAQ #

What is the difference between sort -u and sort | uniq? Both produce the same output for simple deduplication. sort -u is slightly more efficient. sort | uniq is more flexible because uniq supports options like -c (count occurrences) and -d (show only duplicates) that sort -u does not.

Does uniq modify the input file? No. uniq reads from a file or standard input and writes to standard output. The original file is never modified. To save the result, use redirection: sort file.txt | uniq > deduped.txt.

How do I count unique lines in a file? Pipe through sort, uniq, and wc : sort file.txt | uniq | wc -l.

How do I find lines that only appear in one of two files? Merge both files and use uniq -u: sort file1.txt file2.txt | uniq -u. Lines shared by both files become duplicates in the merged sorted stream and are suppressed. Lines that exist in only one file remain unique and are printed.

Can uniq work on columns instead of full lines? Yes. Use -f N to skip the first N fields, -s N to skip the first N characters, or -w N to limit comparison to the first N characters. This lets you deduplicate based on a portion of each line.

Conclusion #

The uniq command is a focused tool for filtering and counting duplicate lines. It is most effective when used after sort in a pipeline and pairs naturally with wc , grep , and head for text analysis tasks.

If you have any questions, feel free to leave a comment below.

top is a command-line utility that displays running processes and system resource usage in real time. It helps you inspect CPU usage, memory consumption, load averages, and process activity from a single interactive view.

This guide explains how to use top to monitor your system and quickly identify resource-heavy processes.

top Command Syntax #

The syntax for the top command is as follows:

top [OPTIONS]

Run top without arguments to open the interactive monitor:

top

Understanding the top Output #

The screen is split into two areas:

• Summary area — system-wide metrics displayed in the header lines
• Task area — per-process metrics listed below the header

A typical top header looks like this:

top - 14:32:01 up 3 days, 4:12, 2 users, load average: 0.45, 0.31, 0.28
Tasks: 213 total, 1 running, 212 sleeping, 0 stopped, 0 zombie
%Cpu(s): 3.2 us, 1.1 sy, 0.0 ni, 95.3 id, 0.2 wa, 0.0 hi, 0.1 si, 0.0 st
MiB Mem : 15886.7 total, 8231.4 free, 4912.5 used, 2742.8 buff/cache
MiB Swap: 2048.0 total, 2048.0 free, 0.0 used. 10374.2 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1234 www-data 20 0 123456 45678 9012 S 4.3 0.3 0:42.31 nginx
987 mysql 20 0 987654 321098 12345 S 1.7 2.0 3:12.04 mysqld
5678 root 20 0 65432 5678 3456 S 0.0 0.0 0:00.12 sshd

CPU State Percentages #

The %Cpu(s) line breaks CPU time into the following states:

• us — time running user-space (non-kernel) processes
• sy — time running kernel processes
• ni — time running user processes with a manually adjusted nice value
• id — idle time
• wa — time waiting for I/O to complete
• hi — time handling hardware interrupt requests
• si — time handling software interrupt requests
• st — time stolen from this virtual machine by the hypervisor (relevant on VMs)

High wa typically points to a disk or network I/O bottleneck. High us or sy points to CPU pressure. For memory details, see the free command. For load average context, see uptime .

Task Area Columns #