Find the dpkg Lock Owner

A Debian or Ubuntu host reports a dpkg lock and you need the owning PID.

Command

sudo lsof /var/lib/dpkg/lock-frontend /var/lib/dpkg/lock 2>/dev/null

Before you run this

System impact: Read-only. Output may expose users, paths, tokens, keys, IPs, process arguments, or log details.

When not to use it: Do not remove lock files just because lsof is empty; confirm package state first.

Process names and PIDs holding dpkg lock files, or no output if no process has them open.

Read-only, sensitive output. Nothing changes. The command reads current state and prints diagnostic evidence.

May require elevated permissions on protected paths or service-owned files.

Recovery / rollback: no state is changed.

Use after checking package-manager processes on Debian or Ubuntu.

Do not remove lock files just because lsof is empty; confirm package state first.

Example run

These are the commands shown for inspection. Treat them as an example, not proof that your system will behave identically.

next steps

Linux Survival Basics Can be slow

The disk was full. The fastest clue was the folder, not the file.

du -sh /var/* 2>/dev/null | sort -h

Linux Survival Basics Sensitive output

Look at one target process, not the whole host, when pressure is scoped.

sudo lsof -p 1234 | head

Linux Survival Basics Sensitive output

Count handles for the target process before raising limits.

sudo lsof -p 1234 | wc -l

Linux Survival Basics Can be slow

A package lock is usually a symptom, not the first thing to delete.

Linux Survival Basics Can be slow

The disk was full, but guessing at folders was the slow part.

find /var -type f -printf '%s %p\n' | sort -nr | head -20

next diagnostic step

Study mapping

Use this as independent command practice: read the notes, predict the output, then compare it with the example before using a real shell.

Independent study support only. No affiliation, endorsement, exam dumps, or real exam questions.