Feature. It is the F_WRLCK operation which takes the lock. I suppose this avoids having to deal with stale lock files from dead zoneadm's.
Similar for the door. The door file is he who fattaches, not he who creates the door file. Saying that, I don't see a problem with the unlock/fdetach operations removing these files, as long at they are truely done, and it ok for a new lock/door to be created. -Steve On Thu, Dec 10, 2009 at 04:37:17PM +0100, Frank Batschulat (Home) wrote: > is it to be expected that after no zoneadm/zoneadmd is running > anymore, /var/run/zones still contains the corresponding lock files ? > > (also I looked at the current threadlist of my system and no zone releated > kernel threads are running anymore) > > osoldev.root./var/run/zones.=> zoneadm list -cp > 0:global:running:/::ipkg:shared > -:zone2:configured:/tank/zones/zone2::ipkg:shared > osoldev.root./var/run/zones.=> ps -eafd|grep zone > root 2961 2734 0 16:35:06 pts/2 0:00 grep zone > osoldev.root./var/run/zones.=> ls -la > total 16 > drwx------ 2 root root 335 Dec 10 12:23 . > drwxr-xr-x 11 root sys 2423 Dec 10 12:21 .. > -rw-r--r-- 1 root root 0 Dec 10 12:23 index.lock > -rw------- 1 root root 0 Dec 10 12:21 zone1.zoneadm.lock > -rw------- 1 root root 0 Dec 10 12:21 zone1.zoneadmd_door > > this was after a zone boot/zone halt/zone uninstall/zone delete cycle. > > bug, feature ? > > --- > frankB > _______________________________________________ > zones-discuss mailing list > zones-discuss@opensolaris.org _______________________________________________ zones-discuss mailing list zones-discuss@opensolaris.org
