dpkg uses a lock file (
/var/lib/dpkg/lock), when in use.
- Why are these lockfiles needed?
- Why are multiple instances not possible?
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. It only takes a minute to sign up.Sign up to join this community
This is not a
dpkg-specific issue (as the title of my edit suggested). Rather, this is something that every package manager (of which I am aware) does; and for good reason. Though, I do understand why it might be confusing.
Package managers rely on databases to track the information for installed packages. If multiple users attempt to write to a database at the same time, it has a high chance of corrupting data (which would really screw with the system).
As a result, many (all?) package managers rely on a lockfile to signal that the database is being written to, so another client should not be allowed to do so.
Note that intelligent package managers may be able to determine when a request is read-only and might not need to lock the database. As a result; it is possible for some actions to be able to be run concurrently where others will not be.
The lock file is used to prevent parallel execution of multiple instances.
Why is this important for a package managers?
A package manager — from a high level view — is a program which applies complex changes to the hard disk.
The changes cannot be done in one step (“atomic”), so there are multiple steps; many of the steps depend on the result of earlier steps.
So, the package manager needs to either analyze the hard disk before executing each step, or simply analyze it once and keep track of the changes it applies itself. The first option is extremely slow. The second requires that no other instance make changes.
There are many other problems that could appear.
It is not impossible to implement a package manager that can work in parallel, but it’s too complicated to be worth it. As in, You cannot imagine how complicated. Really.
rpm and most other traditional package managers) work by installing packages into a global space, which means that packages can conflict with each other (e.g.
B can't be installed at the same time, because they both install
/usr/lib/libfoo.so). Package managers must detect such conflicts and reject such installation requests in order to keep the system in a consistent state. Having multiple instances of the package manager running at the same time would be very complicated and error prone.
Conflict-free package managers (e.g. http://0install.net) can and do allow multiple packages to be installed in parallel¹, and don't need lock files (
B/libfoo.so will go in different directories).
1 Parallel both in the sense of being present and available on the system at the same time, and in the sense of being downloaded and added to the system concurrently.