Bugzilla – Bug 1668
image locking needed to prevent race conditions
Last modified: 2010-01-29 04:16:05 UTC
You need to log in before you can comment on or make changes to this bug.
pkg write operations is missing locking facility. It's possible to run pfexec pkg install SUNWmysql5 from two different terminals at the same time. Both appear to run and finish with success. keyword: sst-osp
To further clarify the importance of the issue: The same goes when you uninstall package dependency of package currently being installed. In one terminal: pkg install SUNWbinutils pkg install SUNWgcc In second terminal, while SUNWgcc is downloading/installing: pkg uninstall SUNWbinutils SUNWgcc installation proceeds successfully even if dependency is missing. This leads to broken functionality.
Moving to the correct Product/Component.
Adjusting priority, severity, accepting.
Created an attachment (id=462) [details] pkg install log
Another manifestation of this problem rises on system with ´flush-content-cache-on-success = True´ in /var/pkg/cfg_cache. 1. Issue two separate pkg installs 2. one finishes first and starts deleting /var/pkg/download contents 3. the second one bails out with internal error (see the attachment) my pkg version is 093ca22da67c
*** Bug 4860 has been marked as a duplicate of this bug. ***
*** Bug 6909 has been marked as a duplicate of this bug. ***
*** Bug 11639 has been marked as a duplicate of this bug. ***
*** Bug 11760 has been marked as a duplicate of this bug. ***
*** Bug 12693 has been marked as a duplicate of this bug. ***
Starting work on this.
Webrev and explanation of approach forthcoming.
Implementation is roughly as follows: When performing image-modifying operations (such as install, metadata refresh, update, configuration change, etc.): The API attempts to obtain an exclusive lock using lockf on the $IMGDIR/lock file. If it cannot, an ImageLockedError is raised with the information found in the lock file as part of the error message. If it obtains the lock, it writes information about the caller into the lock file. In addition, any time a plan is created for modifying the image (install, update, repair, fix, etc.), a timestamp of the image's state is stored. If that state timestamp is different from the current one after obtaining the image lock at the beginning of each phase of the operation (prepare, preexecute, execute) an InvalidPlanError will be raised and the operation aborted with an appropriate message.
Resolved in changeset 1710 / 139720e2e756da4246adf44c7f9cdbcb77d185d6.