Why can't I dtrace processes running in a jail from the host?
markj at freebsd.org
Fri Aug 10 18:34:27 UTC 2018
On Fri, Aug 10, 2018 at 09:15:22AM +0200, Patrick M. Hausen wrote:
> > Am 09.08.2018 um 16:52 schrieb Mark Johnston <markj at freebsd.org>:
> > For userland static probes to be globally visible, the process needs to
> > register them with the kernel when it starts. This is done
> > automatically using a constructor which issues ioctls to
> > /dev/dtrace/helper, hence the requirement for /dev/dtrace/* in the jail.
> I figured as much. Enabling /dev/dtrace/* in the jail and restarting
> the jail made the probes visible in the host system
> I'm still somewhat stuck. What I'm trying to do is track down some
> performance problems in a large complex PHP web application.
> I have done this in the past on "regular" setups without jails
> and with PHP 5.6 compiled with dtrace support using
> /usr/local/share/dtrace-toolkit/Php/* ...
> This setup is jailed with PHP 7.2, dtrace support seems to be the
> default for the port.
> I'm specifically after
> php-fpm dtrace_execute_ex function-entry
> php-fpm dtrace_execute_ex function-return
> of course, to see where the application spends it's CPU cycles.
> But regardless if I'm doing this on the host or in the jail, I only get
> these results:
> dtrace -m php\*
> Nothing else. Still `dtrace -m php\* -l` does show all the probes.
Indeed, I can reproduce this. Peering at the zend source code, it seems
that there's a difference in how the dtrace_execute_ex hook gets
installed: with 5.6, it's unconditional so long as zend is compiled with
HAVE_DTRACE. In 7.2, the php process needs to have USE_ZEND_DTRACE=1
set in its environment for the dtrace function execution hook to be
More information about the freebsd-virtualization