dtrace in a branded zone?

[Drew Balfour]

Howdy all,

I'm trying to run dtrace in an on10 branded zone on an onnv machine:

# zoneadm list -v
ID NAME STATUS PATH BRAND IP
0 global running / ipkg shared
10 zfstestzone running /export/home/zfstestzone solaris10 shared

I've given the zone dtrace privs:

# zonecfg -z zfstestzone info limitpriv
limitpriv: default,dtrace_proc,dtrace_user

but it doesn't seem to work:

# zlogin -l root zfstestzone
[Connected to zone 'zfstestzone' pts/7]
Last login: Wed Dec 15 08:14:17 on pts/7
Oracle Corporation SunOS 5.10 Generic Patch January 2005
You have new mail.
# dtrace -l | grep " stat "
78297 syscall stat entry
78298 syscall stat return

# dtrace -n 'syscall::stat:*' -c 'ls /'dtrace: description 'syscall::stat:*'
matched 2 probes
bin export mnt proc
ts-auto-pool.dat
boot home net rpool
usr
core kernel opt sbin
var
dev lib output.stf_execute.7348
system zfs-test-run.sh
etc lost+found platform tmp
zonepool
dtrace: pid 4879 has exited
#

Am I missing something? Is it not supposed to work, or is this a bug? Nothing
popped up in either a bug search, or a mail archive search.

Thanks,

Drew

[James Litchfield]

Try running truss first to see what you should look for - fstat64 in
this case.

# truss /usr/bin/ls
...
open("/", O_RDONLY|O_NDELAY|O_LARGEFILE) = 3
fstat64(3, 0xFFBFF978) = 0
fcntl(3, F_SETFD, 0x00000001) = 0
getdents64(3, 0x0002F2A0, 8192) = 840
getdents64(3, 0x0002F2A0, 8192) = 0
close(3) = 0
ioctl(1, TCGETA, 0xFFBFDBD4) = 0
fstat64(1, 0xFFBFDAF0) = 0
1 export log_tmp opt usr
write(1, " 1 ".., 68) = 68
bin hadoop lost+found platform var
...

Jim
---

Post by Drew Balfour
Howdy all,
# zoneadm list -v
ID NAME STATUS PATH
BRAND IP
0 global running /
ipkg shared
10 zfstestzone running /export/home/zfstestzone
solaris10 shared
# zonecfg -z zfstestzone info limitpriv
limitpriv: default,dtrace_proc,dtrace_user
# zlogin -l root zfstestzone
[Connected to zone 'zfstestzone' pts/7]
Last login: Wed Dec 15 08:14:17 on pts/7
Oracle Corporation SunOS 5.10 Generic Patch January 2005
You have new mail.
# dtrace -l | grep " stat "
78297 syscall stat entry
78298 syscall stat return
# dtrace -n 'syscall::stat:*' -c 'ls /'dtrace: description
'syscall::stat:*' matched 2 probes
bin export
mnt proc ts-auto-pool.dat
boot home
net rpool usr
core kernel
opt sbin var
dev lib
output.stf_execute.7348 system zfs-test-run.sh
etc lost+found
platform tmp zonepool
dtrace: pid 4879 has exited
#
Am I missing something? Is it not supposed to work, or is this a bug?
Nothing popped up in either a bug search, or a mail archive search.
Thanks,
Drew
_______________________________________________
dtrace-discuss mailing list

[Drew Balfour]

Try running truss first to see what you should look for - fstat64 in this case.

I should have specified in the first post; the same dtrace works fine in the
global zone, so that's not the problem:

# dtrace -n 'syscall::stat:*' -c "ls /"
dtrace: description 'syscall::stat:*' matched 2 probes
bin etc kernel net rmdisk
shared ts-auto-pool.dat wwss
boot export lib opt root
src usr zonepool
dev home media platform rpool
system var
devices import micro proc sbin
tmp workspace
doe java mnt re scde
ts-auto-pool ws
dtrace: pid 4947 has exited
CPU ID FUNCTION:NAME
0 78297 stat:entry
0 78298 stat:return
0 78297 stat:entry
0 78298 stat:return
0 78297 stat:entry
0 78298 stat:return
0 78297 stat:entry
0 78298 stat:return
0 78297 stat:entry
0 78298 stat:return
0 78297 stat:entry
0 78298 stat:return
0 78297 stat:entry
0 78298 stat:return
0 78297 stat:entry
0 78298 stat:return


-Drew

[Mike Gerdts]

Post by Drew Balfour
Howdy all,
# zoneadm list -v
 ID NAME             STATUS     PATH                           BRAND    IP
  0 global           running    /                              ipkg
shared
 10 zfstestzone      running    /export/home/zfstestzone       solaris10
shared
# zonecfg -z zfstestzone info limitpriv
limitpriv: default,dtrace_proc,dtrace_user
# zlogin -l root zfstestzone
[Connected to zone 'zfstestzone' pts/7]
Last login: Wed Dec 15 08:14:17 on pts/7
Oracle Corporation      SunOS 5.10      Generic Patch   January 2005
You have new mail.
#  dtrace -l | grep " stat "
78297    syscall                                                stat entry
78298    syscall                                                stat return
# dtrace -n 'syscall::stat:*' -c 'ls /'dtrace: description 'syscall::stat:*'
matched 2 probes
bin                      export                   mnt
 proc                     ts-auto-pool.dat
boot                     home                     net
 rpool                    usr
core                     kernel                   opt
 sbin                     var
dev                      lib                      output.stf_execute.7348
system                   zfs-test-run.sh
etc                      lost+found               platform
tmp                     zonepool
dtrace: pid 4879 has exited
#
Am I missing something? Is it not supposed to work, or is this a bug?
Nothing popped up in either a bug search, or a mail archive search.

Widening the net a little bit to show all system calls that it is
doing may give a bit more of a hint. It looks to me that you should
be looking for fstatat64 system calls. Notice I added -F to the ls
options to force a stat of each directory entry. This is running on
bits a little newer than Solaris 11 Express.

# uname -a
SunOS s10-1 5.10 Generic_Virtual i86pc i386 i86pc

# dtrace -n 'syscall:::entry /pid == $target/ { trace(probefunc) }' -c 'ls -F /'
dtrace: description 'syscall:::entry ' matched 232 probes
<ls output trimmed>
dtrace: pid 273611 has exited
CPU ID FUNCTION:NAME
2 29 write:entry write
2 29 write:entry write
2 29 write:entry write
2 29 write:entry write
2 29 write:entry write
2 29 write:entry write
2 29 write:entry write
2 29 write:entry write
2 29 write:entry write
2 29 write:entry write
2 29 write:entry write
2 29 write:entry write
2 29 write:entry write
2 29 write:entry write
2 29 write:entry write
2 25 rexit:entry rexit
3 259 munmap:entry munmap
3 225 setcontext:entry setcontext
3 275 getrlimit:entry getrlimit
3 83 getpid:entry getpid
3 225 setcontext:entry setcontext
3 255 mmap:entry mmap
3 137 sysi86:entry sysi86
3 77 brk:entry brk
3 77 brk:entry brk
3 69 gtime:entry gtime
3 141 ioctl:entry ioctl
3 291 sysconfig:entry sysconfig
3 141 ioctl:entry ioctl
3 77 brk:entry brk
3 77 brk:entry brk
3 167 fstatat64:entry fstatat64
3 169 openat:entry openat
3 157 fcntl:entry fcntl
3 167 fstatat64:entry fstatat64
3 359 brandsys:entry brandsys
3 427 getdents64:entry getdents64
3 167 fstatat64:entry fstatat64
3 167 fstatat64:entry fstatat64
3 167 fstatat64:entry fstatat64
3 167 fstatat64:entry fstatat64
3 167 fstatat64:entry fstatat64
...

[John Harres]

I believe this is the actual problem we're fighting:

zfstestzone# dtrace -Z -n 'pid$target::zfs_do_create:return {
printf("%d", arg0); }' -c "/usr/sbin/zfs create
zonepool/zonectr0/testfs.27814"
dtrace: description 'pid$target::zfs_do_create:return ' matched 0 probes
cannot share 'zonepool/zonectr0/testfs.27814': : share(1M) failed
filesystem successfully created, but not shared
dtrace: pid 4710 has exited

It appears to be dying due to zfs_do_create -> zfs_share ->
zfs_share_proto -> zfs_init_libshare but there's no way we've been able
to see inside to dig down into why due to dtrace just not firing.

Any ideas as to why?

TIA,
John