On Tue, Sep 29, 2009 at 10:49:09AM -0500, Shawn Walker wrote: > Alan Steinberg wrote: >> There was some catalog rework done for Build 124. My initial testing >> saw that if I looked at the /var/pkg/catalog immediately after >> rebooting, I saw the regular contents in /var/pkg/catalog. But after a >> few minutes I looked again and also saw that /var/pkg/catalog was no >> longer there (and the new structure was in place instead). >> >> The catalog data probably gets rebuilt and restructured during the >> initial reboot. Assuming that's the problem, I think we need to make >> sure that we document something to the effect that after reboot you >> should wait a short while before attempting package operations. > > So, I suspect the problem being seen here is that we currently don't > have any locking logic in place. On reboot, the updatemanager refresh > process is going to run in the background, which is going to trigger an > upgrade of the image. But while that process is running, the pkg > command and the GUI aren't going to work correctly. > > Because we don't have a locking mechanism in place yet that prevents > multiple clients from modifying/accessing the image while it is being > changed, I'm uncertain what to do here. I'm open to suggestions > though...
This might also explain how manifests are getting corrupted in bug 6011. They parse correctly when we download them, but subsequent re-loads fail. Two processes writing to the same file without any locking could certainly cause this problem. The manifest code doesn't use a method to keep its tempfiles unique, so two writers could be modifying the same file, and then rename it into place. This is an extension of similar comments Shawn made earlier this morning on bug 11169. http://defect.opensolaris.org/bz/show_bug.cgi?id=11169#c4 -j _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
