Concurrent apt operations blocked by dpkg frontend lock

Direct answer

Yes. The dpkg frontend lock serializes concurrent package operations on Kali Linux by design. It is standard APT/dpkg behavior on Debian-derived systems, not a consequence of the kali-linux-everything meta-package or Kali repository configuration. You should avoid parallel apt invocations during rolling-release full-upgrade cycles.

Confirmed facts

• The lock file /var/lib/dpkg/lock-frontend prevents two front ends from modifying the dpkg package database at the same time.
• Only one apt or dpkg process can hold the frontend lock; others block until it is released.
• APT may download packages in parallel, but unpacking and configuration remain sequential and lock-protected.
• Large meta-packages such as kali-linux-everything increase latency through dependency resolution and sequential package processing, not through additional locking.

Likely explanation

If two apt processes run at once, the second blocks on the frontend lock. The perceived latency is therefore serialization plus the normal cost of resolving a very large dependency graph. The lock itself does not slow a single well-formed operation.

Steps for this case

1. Run package operations one at a time; do not launch parallel apt, apt-get, or dpkg invocations.
2. Before assuming a stuck lock, identify the holder: sudo lsof /var/lib/dpkg/lock-frontend
3. If a process is active, wait for it to finish or inspect it with ps.
4. Do not delete /var/lib/dpkg/lock-frontend while a process holds it; forced removal can corrupt the dpkg database.
5. For rolling-release upgrades, use a single sudo apt full-upgrade invocation and let it complete.

Verification

Attempt a second apt install in another terminal while the first runs; the second should report that it cannot obtain the lock. Confirm the active holder with:

sudo lsof /var/lib/dpkg/lock-frontend
sudo fuser -v /var/lib/dpkg/lock-frontend

Assumptions and uncertainty

This assumes a standard Kali rolling release with root or sudo access and no local APT configuration that disables locking. Message text varies by front end, so rely on lock behavior rather than exact wording. If you are seeing slowness without concurrent processes, the cause is likely dependency resolution for kali-linux-everything rather than lock contention; that distinction does not change the recommendation to serialize operations.