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