On 08/08/12 10:56, John D Groenveld wrote:
This morning's "zoneadm -z search-1 attach -F" and boot tripped
over a funky mount:

[Wednesday, August  8, 2012 10:56:46 AM EDT] Mounting 
rpool/var/zones/search-1/rpool/export at /tmp/tmp.zxa40u/export with ZFS 
temporary mount
[Wednesday, August  8, 2012 10:56:46 AM EDT] Mounting 
rpool/var/zones/search-1/rpool/export/home at /tmp/tmp.zxa40u/export/home with 
ZFS temporary mount
cannot unmount '/tmp/tmp.zxa40u/export/home': Device busy
cannot unmount '/tmp/tmp.zxa40u/export': Device busy
rmdir: directory "/tmp/tmp.zxa40u": Directory not empty
[Wednesday, August  8, 2012 10:56:47 AM EDT] Manual migration of export 
required.  Potential conflicts in
/var/opt/zones/search-1/root/export and rpool/var/zones/search-1/rpool/export.
[Wednesday, August  8, 2012 10:56:47 AM EDT]       Zone BE root dataset: 
[Wednesday, August  8, 2012 10:56:47 AM EDT]                      Cache: Using 

Haven't seen this race condition in several months of daily
zone detach/attach's. My other zones came up cleanly.

Do you say race condition because you had something else (find, backups, etc.) that was crawling /tmp at the same time? Or is there something in Solaris that you are saying raced against this temporary mount? How would things be different if we chose any other location for temporary mounts?

I'm running Solaris 11 SRU 8.5.
The work-around was to halt the zone, detach, zfs umount
rpool/var/zones/search-1/rpool/export/home and
rpool/var/zones/search-1/rpool/export, attach and boot.

Where in the zone machinery does the code set the zone mountpoints
to global's TMPDIR?

This looks to be part of the attach path that is looking for the Solaris 11 Express dataset layout. See migrate_export in /usr/lib/brand/shared/common.ksh. The mount point is chosen with "mktemp -d". Note that this is a private implementation detail that you happen to be able to see because it is written in ksh. It may change at any time (sru, update, release) without notice.

Mike Gerdts
Solaris Core OS / Zones                 http://blogs.oracle.com/zoneszone/

zones-discuss mailing list

Reply via email to