If you have explored Linux system directories, you may have seen /var/lock. It is associated with lock files: markers or operating-system locks that help programs coordinate access to shared resources.

An APT error like this is related, but its lock file is usually under /var/lib/apt, not /var/lock:

E: Could not get lock /var/lib/apt/lists/lock.
It is held by process 1234 (apt)

The distinction matters: deleting a lock file does not safely end the process holding the lock.

/var/lock

The Filesystem Hierarchy Standard reserves /var/lock for lock files used to coordinate access to shared resources. Historically, it has been used for things such as serial-device locks. On many modern Linux systems, /var/lock is a symbolic link to /run/lock.

Inspect it with:

$ ls -ld /var/lock
$ readlink -f /var/lock

/run holds runtime data and is commonly cleared during boot. As a result, locks stored there are generally temporary. The exact layout and which programs use it depend on the Linux distribution and software.

How do lock files work?

A lock helps cooperating programs avoid using a shared resource in conflicting ways. For example, a script can use the flock utility to acquire an exclusive lock before running:

$ flock -n /var/lock/myscript.lock ./myscript.sh

Here, flock -n requests a lock without waiting. If another process already holds that lock, the command exits instead of running the script. Both programs must use the same locking mechanism and lock path for this coordination to work.

Not every lock is a file in /var/lock. Some applications use lock files elsewhere, and others use kernel-managed advisory locks on files. A lock file’s presence alone does not prove that a process currently holds a lock.

Why does APT report a lock error?

APT and dpkg use locks to prevent package operations from interfering with each other. These locks are commonly located in directories such as /var/lib/apt and /var/lib/dpkg, not /var/lock.

If an APT message says a lock is held by a process, another package operation may be running—for example, an update, an installation, or an automatic upgrade. Wait for it to finish, then retry.

To inspect the reported process, replace 1234 with the process ID shown in the error:

$ ps -fp 1234

You can also check for package manager processes:

$ ps -ef | grep -E '[a]pt|[d]pkg|unattended-upgrade'

If the process is active, let it finish. If it appears stuck, investigate its status and logs before taking action. Avoid starting another package operation at the same time.

Is it safe to delete a lock file?

Do not delete an APT or dpkg lock file just because it exists. Package managers can hold operating-system locks on these files, and removing a file does not release a lock held by a running process. It can allow another package operation to interfere with the first and may damage package state.

If no package manager is running but APT still reports a problem, first confirm that the process has ended and read the complete error message. Follow your distribution’s recovery guidance rather than removing files blindly. Rebooting is not a universal first step, especially if a package operation may still be active.

Do lock files survive a reboot?

It depends on where the lock is stored. Files under /run are normally runtime data and are cleared during boot. Other lock files may be stored under persistent locations. Do not infer that a lock is stale solely from its age or filename; check whether a process is using the associated resource.

Key points

• /var/lock is a standard location for some resource lock files; many systems link it to /run/lock.
• APT locks are normally found under /var/lib/apt or /var/lib/dpkg, not /var/lock.
• A lock file’s existence does not necessarily mean a lock is currently held.
• Never delete an APT/dpkg lock file while a package manager may be running.
• Use the locking method expected by the application when coordinating your own scripts.

Lock files help Linux programs coordinate access to shared resources. Since APT’s locks are usually stored under /var/lib/apt or /var/lib/dpkg, an APT lock error is separate from /var/lock. If you see one, check which process holds it and let active package operations finish—deleting the lock file can cause package-management problems.

We hope this was helpful.
Keep learning. Keep exploring. Stay secure.