On Tue 03 Jan 2012 at 04:02PM, John D Groenveld wrote:
> In message <20120103203031.gl24...@ultra24.us.oracle.com>, Mike Gerdts writes:
> >Can you provide the following:
> >
> >----------------%<---------------
> >zfs list -o name,mountpoint,canmount,mounted -r rpool/var/zones/search-1
> # zfs list -o name,mountpoint,canmount,mounted -r rpool/var/zones/search-1
> NAME                                        MOUNTPOINT                        
> rpool/var/zones/search-1                    /var/opt/zones/search-1           
>               on      yes
> rpool/var/zones/search-1/rpool              
> /var/opt/zones/search-1/root/rpool              on      yes
> rpool/var/zones/search-1/rpool/ROOT         legacy                            
>           noauto       no
> rpool/var/zones/search-1/rpool/ROOT/zbe-3   /var/opt/zones/search-1/root      
>           noauto      yes
> rpool/var/zones/search-1/rpool/export       
> /var/opt/zones/search-1/root/export             on      yes
> rpool/var/zones/search-1/rpool/export/home  
> /var/opt/zones/search-1/root/export/home        on      yes
> I couldn't figure why from within the zone zfs mount was complaining
> that the export and export/home datasets were busy.
> Then from global I noticed rpool/var/zones/search-1/rpool/export and
> export/home had the temporary mountpoint which was completely
> unexpected.
> After I halt'd and detach'd my zone, umount'd the datasets and
> attach'd the zone the mountpoints corrected themselves.

It kinda sounds like something from the global zone had stepped into
some filesystems that were temporarily mounted during an attach process.
This is backed up by the evil in the attach log:

   Lots of evil in attach log:
   [Sun Jan  1 21:11:30 EST 2012] Mounting 
rpool/var/zones/search-1/rpool/export/home at /tmp/tmp.7kayqJ/export/home with 
ZFS temporary mount
   cannot unmount '/tmp/tmp.7kayqJ/export/home': Device busy
   cannot unmount '/tmp/tmp.7kayqJ/export': Device busy
   rmdir: directory "/tmp/tmp.7kayqJ": Directory not empty

Do you by any chance have a /tmp cleaner (or something else that does a
find or du) running at roughly the same time?  If so, the -mount option
to find or the -d option to du may be a help to prevent recurrence.
/tmp/tmp.7kayqJ should have been created rwx by root only.

> >zonecfg -z search1 info dataset
> >for ds in $(zonecfg -z z1 info dataset | nawk '$1 == "name:" {print $2}')
> >do
> >     echo Dataset: $ds
> >     zfs list -o name,mountpoint,canmount,mounted,zone $ds
> >done
> >zonecfg -z search1 info fs

Going back to the beginning of the thread I see you had already given
this info.  Sorry 'bout that.

> # zonecfg -z search-1 info
> zonename: search-1
> zonepath: /var/opt/zones/search-1
> brand: solaris
> autoboot: true
> bootargs: -m verbose
> file-mac-profile:
> pool:
> limitpriv:
> scheduling-class:
> ip-type: exclusive
> hostid:
> fs-allowed:
> fs:
>         dir: /ematrix
>         special: tank/ematrix
>         raw not specified
>         type: zfs
>         options: []
> net:
>         address not specified
>         allowed-address not specified
>         configure-allowed-address: true
>         physical: vnic3
>         defrouter not specified
> capped-memory:
>         physical: 3G
> >Also, any details about changes in the zone configuration and/or package
> >updates since the previous successful backup would be helpful.
> I made no changes.
> The other zones on the system had no issues.

It's starting to look like a race with something else on the system.

If there is something beyond your control that likes to walk through
/tmp as root, you could probably add the following to the cron job.

mkdir /var/attachtmp
mount -F tmpfs - /var/attachtmp
chmod 1777 /var/attachtmp
export TMPDIR=/var/attachtmp

# Do the stuff you normally do here

unset TMPDIR
umount /var/attachtmp
rmdir /var/attachtmp

Adjust as your environment requires.

Mike Gerdts
Solaris Core OS / Zones                 http://blogs.oracle.com/zoneszone/
zones-discuss mailing list

Reply via email to