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 opera
On 12/ 8/09 11:50 AM, xx wrote:
when updating from 126 to 128, one zone would attach:
init...@dogpatch:~/.VirtualBox/HardDisks$ pfexec zoneadm -z ldap attach -U
Log File: /var/tmp/ldap.attach_log.9hay7p
Attaching...
Global zone version: ent...@0.5.11,5.11-0.128:20091125T051747Z
Non-Gl
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:gl
On Wed, 09 Dec 2009 23:54:05 +0100, Jordan Vaughan
wrote:
> I need someone to review my fix for
>
> 6882732 unpacking archive with extended file attributes reports errors
>
> The webrev is accessible via
>
> http://cr.opensolaris.org/~flippedb/onnv-s10c
looks good to me.
cheers
---
frankB