How to Install htop on Rocky Linux 10, 9 and 8

Rocky Linux keeps htop outside the default BaseOS, AppStream, and Extras repositories, so the package source matters before you run the install command. To install htop on Rocky Linux, use the EPEL package for the lowest-maintenance system install, or build the latest upstream release from GitHub when you specifically need a user-managed copy under your home directory.

The EPEL method works across Rocky Linux 10, 9, and 8 and updates through DNF. The source-build method installs htop under ~/.local/opt/htop, exposes a friendly htop command through ~/.local/bin, and includes a repeatable update helper that resolves the current stable GitHub release each time it runs.

Install htop on Rocky Linux

Check Whether htop Is Already Installed

Start with a read-only check so you know whether your shell already resolves an htop command:

command -v htop && htop --version

If the command prints no path, install htop with one of the methods below. If it prints a path, note whether the command comes from /usr/bin or ~/.local/bin before changing methods.

Choose an htop Installation Method

Rocky Linux has two practical htop paths for most readers. EPEL is the recommended method because DNF owns the package, dependencies, updates, and removal. The source build is for users who intentionally want the current upstream htop release outside the RPM database.

Method	Source	Update Behavior	Best For	Trade-offs
EPEL package	Fedora EPEL through Rocky Extras epel-release	Through dnf upgrade	Most servers, desktops, and scripted installs	Tracks EPEL’s packaged branch, not the newest upstream release
GitHub source build	Upstream htop GitHub Releases	Rerun update-htop-source	Users who need the latest stable upstream htop under their own account	Requires compiler packages and is not tracked by RPM or DNF

Use only one htop command path for daily work unless you deliberately want both. If the EPEL package and the source build coexist, your shell runs whichever htop appears first in PATH; verify that with command -v htop.

Check the EPEL htop Package Versions

During validation, EPEL listed htop for Rocky Linux 10, 9, and 8. Rocky’s default BaseOS, AppStream, and Extras repositories did not list an htop candidate, so EPEL is the package source for the RPM method.

Rocky Linux Release	EPEL Package	Runtime Version	Source
Rocky Linux 10	htop-3.3.0-5.el10_0.x86_64	htop 3.3.0	EPEL 10
Rocky Linux 9	htop-3.3.0-1.el9.x86_64	htop 3.3.0	EPEL 9
Rocky Linux 8	htop-3.2.1-1.el8.x86_64	htop 3.2.1	EPEL 8

The core monitoring, search, filtering, tree view, sort, signal, and read-only options in this workflow are available in these EPEL builds. Choose the source build only when a newer upstream release is worth managing separately.

Install htop with EPEL and DNF

Install the EPEL release package from Rocky Extras. This adds the matching EPEL repository for your Rocky major release:

sudo dnf install epel-release

DNF may print a reminder that many EPEL packages need CRB on Rocky Linux 10 and 9, or PowerTools on Rocky Linux 8. Htop installed from EPEL without enabling those repositories during validation, but the broader EPEL setup on Rocky Linux is the better handoff when you plan to use several EPEL packages.

Confirm that EPEL publishes htop for your enabled branch:

dnf --enablerepo=epel repoquery --available htop

Install htop from EPEL:

sudo dnf install htop

Verify the installed package and command path:

rpm -q htop --qf '%{NAME} %{VERSION}-%{RELEASE} %{ARCH}\n'
command -v htop
htop --version

On Rocky Linux 10, the version check prints:

htop 3.3.0

Rocky Linux 9 prints htop 3.3.0, while Rocky Linux 8 prints htop 3.2.1 from the same command.

Build the Latest htop Release from GitHub

The source method builds htop from the upstream release tarball, not from a moving Git checkout. It verifies the published .sha256 sidecar, compares the GitHub API digest when GitHub exposes one, installs into a versioned directory under ~/.local/opt/htop, and links ~/.local/bin/htop to the active build.

Install Source Build Dependencies

Install the compiler, Make, pkg-config compatibility package, ncurses headers, optional htop feature headers, download tools, archive tools, JSON parser, and CA certificates:

sudo dnf install gcc make pkgconf-pkg-config ncurses-devel libcap-devel lm_sensors-devel libnl3-devel curl jq tar xz ca-certificates

These package names resolved on Rocky Linux 10, 9, and 8 without enabling CRB or PowerTools. The build can still differ from the EPEL package because it is compiled under your account and is not an RPM-managed package.

Create the htop Source Update Helper

Create a reusable update-htop-source helper. It resolves the latest stable GitHub release each time it runs and rejects version arguments so this method stays on the current upstream stable release.

create_htop_source_helper() {
  mkdir -p "$HOME/.local/bin"
  case ":$PATH:" in
  *":$HOME/.local/bin:"*) ;;
  *) export PATH="$HOME/.local/bin:$PATH" ;;
  esac

  BASHRC="$HOME/.bashrc"
  PATH_MARKER="LinuxCapable local bin path"
  if [ -f "$BASHRC" ] && ! grep -q "$PATH_MARKER" "$BASHRC"; then
    cat >>"$BASHRC" <<'EOF'

# LinuxCapable local bin path
if [ -d "$HOME/.local/bin" ]; then
  case ":$PATH:" in
    *":$HOME/.local/bin:"*) ;;
    *) PATH="$HOME/.local/bin:$PATH" ;;
  esac
fi
EOF
  fi

  HELPER="$HOME/.local/bin/update-htop-source"
  HTOP_LINK="$HOME/.local/bin/htop"
  HTOP_PREFIX="$HOME/.local/opt/htop"
  HELPER_MARKER="LinuxCapable htop source helper"

  if [ -L "$HELPER" ]; then
    echo "$HELPER is a symlink. Move it before creating the htop helper."
    return 1
  fi

  if [ -e "$HELPER" ] && ! grep -q "$HELPER_MARKER" "$HELPER"; then
    echo "$HELPER already exists and was not created by this workflow. Move it before continuing."
    return 1
  fi

  if [ -L "$HTOP_LINK" ] && [ "$(readlink "$HTOP_LINK")" != "$HTOP_PREFIX/current/bin/htop" ]; then
    echo "$HTOP_LINK already points somewhere else. Move it before installing source-built htop."
    return 1
  elif [ -e "$HTOP_LINK" ] && [ ! -L "$HTOP_LINK" ]; then
    echo "$HTOP_LINK exists and is not a symlink. Move it before installing source-built htop."
    return 1
  fi

  if [ -e "$HTOP_PREFIX/current" ] && [ ! -L "$HTOP_PREFIX/current" ]; then
    echo "$HTOP_PREFIX/current exists and is not a symlink. Move it before updating the htop prefix."
    return 1
  fi

  cat >"$HELPER" <<'EOF'
#!/usr/bin/env bash
# LinuxCapable htop source helper
set -euo pipefail

REPO_API="https://api.github.com/repos/htop-dev/htop/releases/latest"
WORKDIR="${HTOP_SOURCE_WORKDIR:-$HOME/htop-source-build}"
PREFIX_BASE="${HTOP_PREFIX_BASE:-$HOME/.local/opt/htop}"
BIN_DIR="${HTOP_BIN_DIR:-$HOME/.local/bin}"

if [ "$#" -ne 0 ]; then
  echo "This helper always builds the latest stable htop release; run update-htop-source without arguments."
  exit 2
fi

RELEASE_JSON=$(curl -fsSL "$REPO_API")
TAG=$(printf '%s' "$RELEASE_JSON" | jq -r 'select(.draft == false and .prerelease == false) | .tag_name')

if ! [[ "$TAG" =~ ^[0-9]+[.][0-9]+[.][0-9]+$ ]]; then
  echo "Could not resolve a stable htop release tag."
  exit 1
fi

ARCHIVE="htop-${TAG}.tar.xz"
SHA_FILE="${ARCHIVE}.sha256"
BASE_URL="https://github.com/htop-dev/htop/releases/download/${TAG}"

if ! printf '%s' "$RELEASE_JSON" | jq -e --arg name "$ARCHIVE" 'any(.assets[]?; .name == $name)' >/dev/null; then
  echo "Latest htop release does not include $ARCHIVE."
  exit 1
fi

if ! printf '%s' "$RELEASE_JSON" | jq -e --arg name "$SHA_FILE" 'any(.assets[]?; .name == $name)' >/dev/null; then
  echo "Latest htop release does not include $SHA_FILE."
  exit 1
fi

mkdir -p "$WORKDIR" "$PREFIX_BASE" "$BIN_DIR"

EXPECTED_LINK="$PREFIX_BASE/current/bin/htop"

if [ -L "$BIN_DIR/htop" ] && [ "$(readlink "$BIN_DIR/htop")" != "$EXPECTED_LINK" ]; then
  echo "$BIN_DIR/htop already points somewhere else. Move it before installing source-built htop."
  exit 1
elif [ -e "$BIN_DIR/htop" ] && [ ! -L "$BIN_DIR/htop" ]; then
  echo "$BIN_DIR/htop exists and is not a symlink. Move it before installing source-built htop."
  exit 1
fi

if [ -e "$PREFIX_BASE/current" ] && [ ! -L "$PREFIX_BASE/current" ]; then
  echo "$PREFIX_BASE/current exists and is not a symlink. Move it before updating the source-built htop prefix."
  exit 1
fi

if [ -x "$PREFIX_BASE/current/bin/htop" ]; then
  VERSION_LINE=$("$PREFIX_BASE/current/bin/htop" --version | head -n 1 || true)
  INSTALLED_VERSION=${VERSION_LINE#htop }
  INSTALLED_TAG=${INSTALLED_VERSION%%-*}
  if [ "$INSTALLED_TAG" = "$TAG" ]; then
    echo "htop ${TAG} is already installed."
    exit 0
  fi
fi

cd "$WORKDIR"
rm -rf "htop-${TAG}" "$ARCHIVE" "$SHA_FILE"
curl -fLO --progress-bar "$BASE_URL/$ARCHIVE"
curl -fLO --progress-bar "$BASE_URL/$SHA_FILE"
sha256sum -c "$SHA_FILE"

API_DIGEST=$(printf '%s' "$RELEASE_JSON" | jq -r --arg name "$ARCHIVE" '.assets[]? | select(.name == $name) | .digest // empty' | sed -n '1p')
if [[ "$API_DIGEST" == sha256:* ]]; then
  API_SHA=${API_DIGEST#sha256:}
  LOCAL_SHA=$(sha256sum "$ARCHIVE" | awk '{print $1}')
  if [ "$API_SHA" != "$LOCAL_SHA" ]; then
    echo "GitHub API digest does not match the downloaded archive."
    exit 1
  fi
  echo "GitHub API digest verified for $ARCHIVE."
fi

tar -xf "$ARCHIVE"

if [ ! -x "htop-${TAG}/configure" ]; then
  echo "Extracted htop archive does not contain the expected configure script."
  exit 1
fi

cd "htop-${TAG}"
./configure --prefix="${PREFIX_BASE}/${TAG}"
make -j"$(nproc)"
make install

ln -sfnT "${PREFIX_BASE}/${TAG}" "${PREFIX_BASE}/current"
ln -sfnT "${PREFIX_BASE}/current/bin/htop" "${BIN_DIR}/htop"
"${BIN_DIR}/htop" --version | head -n 1
EOF

  chmod +x "$HELPER"
  bash -n "$HELPER"
  hash -r
  command -v update-htop-source
}

create_htop_source_helper && unset -f create_htop_source_helper

The setup block refuses to overwrite unrelated helper files or htop links. It also adds a marked ~/.bashrc guard so new Bash terminals can find ~/.local/bin after the helper creates it.

Build the Latest htop Release

Run the helper to download, verify, build, install, and link the latest stable htop release:

update-htop-source

A successful run ends with the built htop version. Current htop release tarballs can print the release tag twice, such as htop 3.5.1-3.5.1; use the leading version number as the active upstream release.

Refresh Bash’s command cache and confirm your shell resolves the source-built binary under ~/.local/bin:

hash -r
command -v htop
htop --version

Use htop to Monitor and Control Processes

Htop opens as an interactive terminal dashboard. It shows CPU meters, memory and swap usage, load averages, process IDs, users, CPU and memory percentages, and the command behind each process. Press F1, h, or ? inside htop to open its built-in help screen.

Launch htop

Start htop from a terminal:

htop

Limit the process list to your current user when a busy shared server has too much noise:

htop -u "$USER"

Use the arrow keys or mouse to move through the process list. Press F10 or q to exit when you finish checking the system.

Navigate and Sort Processes

Use these keys to scan and reorganize the process view without leaving htop:

Key	Action
Up/Down	Move through the process list
Left/Right	Scroll across columns
F6, <, >, or .	Choose the sort column
F5 or t	Toggle tree view for parent-child process relationships
Mouse click	Select a process or sort by a visible column header

Search and Filter Processes

Search and filter when a long process list hides the task you need:

Key	Action	Example Use
F3 or /	Search and highlight a matching process	Jump to a process named sshd
F4 or \	Filter the visible list	Show only processes containing your username or service name

Current htop filters use text terms rather than full regular expressions. Use simple process names, users, or command fragments when narrowing the display.

Kill or Reprioritize Processes

Use process actions carefully on production servers. Select the target process first, then choose the least disruptive action that fits the problem:

Key	Action	When to Use
F9 or k -> SIGTERM (15)	Ask a process to terminate cleanly	First choice for a stuck user process
F9 or k -> SIGKILL (9)	Force immediate termination	Only when SIGTERM fails and you accept possible data loss
F9 or k -> SIGHUP (1)	Send a hangup signal	Daemons that explicitly support reload-on-HUP behavior
F7 or ]	Raise priority by lowering the nice value	Usually requires root privileges
F8 or [	Lower priority by raising the nice value	Reduce background task priority

Run sudo htop only when you need to manage system-owned processes or adjust priorities that a regular user cannot change.

Customize the htop Display

Press F2 to open htop setup. Use that interface to change meters, columns, colors, and display options, then quit cleanly with F10 or q so htop can save your user settings to ~/.config/htop/htoprc.

• Add meters such as CPU, memory, swap, load average, uptime, systemd units, or sensors when the build supports them.
• Move CPU, memory, PID, user, state, or command columns closer to the left when you monitor narrow terminals over SSH.
• Switch color schemes when the default palette is hard to read in your terminal theme.

Use htop Command-Line Options

Htop options can narrow the process list, adjust refresh timing, or make a read-only monitoring session safer before the interface opens.

Monitor Specific Processes

Track a small set of process IDs without unrelated system activity:

htop -p 1234,5678,91011

Replace the numbers with real PIDs from your system. This is useful when you are watching a parent service, worker process, or short list of related tasks.

Adjust Update Frequency

Slow the refresh interval on resource-constrained systems:

htop -d 30

The -d option uses tenths of seconds, so -d 30 updates every 3 seconds. Lower values refresh faster and can consume more CPU time on busy systems.

Use Read-Only, Keyboard-Only, or Monochrome Mode

Start a read-only htop session when you want monitoring without process-changing actions such as kill or renice:

htop --readonly

Disable mouse input for keyboard-only sessions:

htop --no-mouse

Use monochrome output when a remote terminal theme makes colors hard to read:

htop --no-color

Update htop on Rocky Linux

Update htop with the same method used for installation. Mixing update paths can leave multiple htop binaries on one account, so check command -v htop after switching methods.

Update EPEL htop

Refresh repository metadata and update the EPEL htop package:

sudo dnf upgrade --refresh htop

If DNF reports Nothing to do, your installed EPEL package is already current for the enabled repositories.

Update Source-Built htop

The source helper checks GitHub’s latest stable release, downloads the matching tarball and checksum file, verifies them, rebuilds htop, and updates the user-local symlinks:

update-htop-source

If the latest release is already installed, the helper prints an already-installed message and exits without rebuilding.

Uninstall htop from Rocky Linux

Remove htop with the same method used for installation. The EPEL package and source build own different files, so keep their cleanup paths separate.

Uninstall EPEL htop

Remove the RPM package:

sudo dnf remove htop

Confirm the package is gone:

rpm -q htop

Keep epel-release installed if other EPEL packages still depend on that repository for updates. If htop was the only reason you enabled EPEL, use the EPEL article’s cleanup section instead of deleting repository files by hand.

Uninstall Source-Built htop

The source method creates files under your account. Check the active command path before deleting those files:

command -v htop

The cleanup command removes the source workspace, versioned htop install tree, helper script, and source-method symlink under your account. Back up anything under those paths if you customized the source build manually.

HELPER="$HOME/.local/bin/update-htop-source"

if [ -L "$HOME/.local/bin/htop" ] && [ "$(readlink "$HOME/.local/bin/htop")" = "$HOME/.local/opt/htop/current/bin/htop" ]; then
  rm -f "$HOME/.local/bin/htop"
fi
rm -rf "$HOME/htop-source-build" "$HOME/.local/opt/htop"

if [ -f "$HELPER" ] && grep -q "LinuxCapable htop source helper" "$HELPER"; then
  rm -f "$HELPER"
fi

hash -r

The cleanup leaves the marked ~/.bashrc PATH guard in place because ~/.local/bin is shared by many per-user tools. Remove that marked block manually only if you do not use local user-installed commands.

Confirm your shell no longer resolves the source-built command:

command -v htop

If this still prints a path, another htop method remains installed or another custom binary appears earlier in PATH.

The source cleanup leaves build dependencies installed because they can be shared with other local builds. If you installed them solely for htop, remove only the packages you no longer need and review DNF’s transaction before confirming:

sudo dnf remove gcc make ncurses-devel libcap-devel lm_sensors-devel libnl3-devel

Keep curl, jq, tar, xz, ca-certificates, and pkgconf-pkg-config unless you are deliberately cleaning broader command-line, TLS, archive, or build tooling.

User-specific htop settings can remain after package or source removal. Delete ~/.config/htop only if you want to remove saved color schemes, column layouts, and meter configuration for that account.

Troubleshoot Common htop Issues

Most htop installs are straightforward, but these checks separate package-source, PATH, source-build, terminal, and permission problems.

DNF Cannot Find the htop Package

If DNF cannot find htop, first confirm that EPEL is enabled:

dnf repolist --enabled | grep -E '^epel[[:space:]]'

If that command prints no EPEL row, install the release package and check the candidate again:

sudo dnf install epel-release
dnf --enablerepo=epel repoquery --available htop

Do not add EPEL Next for Rocky Linux. The normal EPEL branch provides htop for Rocky Linux 10, 9, and 8.

EPEL htop Is Older Than the GitHub Release

This is expected. EPEL packages prioritize distro integration and maintenance through DNF, while GitHub Releases carry the upstream htop project. Use the source method only when the newer upstream release is worth managing outside RPM.

Source Helper Cannot Detect the Latest Release

The helper needs GitHub API access and jq parsing. Check that both layers return a stable tag:

curl -fsSL https://api.github.com/repos/htop-dev/htop/releases/latest | jq -r '.tag_name'

If that command fails because of a proxy, firewall, GitHub API rate limit, or temporary upstream outage, fix that access layer and rerun update-htop-source. Do not bypass the checksum step when retrying a failed source build.

Source-Built htop Is Not Found

If the source build succeeds but htop is not found, first check whether the user-local binary works by absolute path:

"$HOME/.local/bin/htop" --version

If that command prints the htop version, reload the Bash startup file, clear Bash’s command cache, and verify the friendly command again:

source "$HOME/.bashrc"
hash -r
command -v htop
htop --version

Terminals that were already open before the helper ran may need the reload step or a fresh terminal window before they see ~/.local/bin.

Terminal Display Looks Broken

If htop displays garbled characters or unreadable colors, first test monochrome mode:

htop --no-color

If monochrome mode works, check the terminal type reported by your session:

echo "$TERM"

Modern terminal emulators usually report xterm-256color or a similar 256-color-capable value. If your terminal reports xterm or linux, try another terminal emulator or keep monochrome mode for that session.

Permission Denied When Changing Priority

Regular users can adjust their own processes only within restricted nice-value ranges. Start htop with elevated privileges when you need to renice system processes or raise process priority:

sudo htop

Select a process and try F7 or F8 again. If the nice value changes, the earlier failure was a privilege boundary rather than an htop install problem.

Conclusion

Htop is ready on Rocky Linux through EPEL or a user-managed upstream source build. Use F4 to filter noisy process lists, F6 to sort by the metric that matters, and --readonly for safer monitoring sessions. For remote checks, install SSH on Rocky Linux and run htop over a secured terminal session.