Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 10 Aug 2018 14:34:19 -0400
From:      Mark Johnston <markj@freebsd.org>
To:        "Patrick M. Hausen" <hausen@punkt.de>
Cc:        freebsd-virtualization@freebsd.org, freebsd-dtrace@freebsd.org
Subject:   Re: Why can't I dtrace processes running in a jail from the host?
Message-ID:  <20180810183419.GA52302@raichu>
In-Reply-To: <8B1BDE9F-BDAD-4CEB-B7A2-8052497F50EA@punkt.de>
References:  <FB08F1C9-C066-4C78-8D35-E2A522ADC8F8@punkt.de> <20180809145258.GA68459@raichu> <8B1BDE9F-BDAD-4CEB-B7A2-8052497F50EA@punkt.de>

next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Aug 10, 2018 at 09:15:22AM +0200, Patrick M. Hausen wrote:
> Hi!
> 
> > Am 09.08.2018 um 16:52 schrieb Mark Johnston <markj@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\*
> 	ZEND_CATCH_SPEC_CONST_CV_HANDLER:exception-caught
> 	php_request_shutdown:request-shutdown
> 	php_request_startup:request-startup
> 	zend_error:error
> 	zend_throw_exception_internal:exception-thrown
> 
> 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
installed.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20180810183419.GA52302>