Re: Why can't I dtrace processes running in a jail from the host?
Good morning, I did some further investigation and with help from Mark was finally able to get it working. Took quite some effort - documentation on the PHP side - NULL :-/ BTW: has anyone ever successfully subscribed to one of the PHP mailing lists? Where is the community of the people developing that stuff? OK, back to topic, in fact I had two issues, one FreeBSD, one PHP related. 1. DTrace'ing jailed userland probes requires /dev/dtrace/* to be visible inside the jail. Hence: [devfsrules_proserver=100] add include $devfsrules_jail add path dtrace/* unhide iocage set devfs_ruleset=100 vpro0069 Voila - dtrace on the host, watch userland probes in the jail. 2. PHP > 5.6 needs the environment variable USE_ZEND_DTRACE to be set to register it's probes. Turned out that it was not sufficient to *configure* that into the PHP FPM worker but you need to set (and export) the variable on the shell before you start the FPM master daemon. Then everything works as expected. What I regularly do in such a case is sh -x /usr/local/etc/rc.d/php-fpm start to find out what command is actually executed in the end. Then call that directly after setting the environment. Result: setenv USE_ZEND_DTRACE 1 limits -C daemon /usr/local/sbin/php-fpm Bingo! Surprisingly enough it is *not* necessary to configure clear_env = no in PHP FPM ... DTrace is active as soon as the master daemon sees that environment variable. Kind regards Patrick -- punkt.de GmbH Internet - Dienstleistungen - Beratung Kaiserallee 13a Tel.: 0721 9109-0 Fax: -100 76133 Karlsruhe i...@punkt.de http://punkt.de AG Mannheim 108285 Gf: Juergen Egeling ___ freebsd-dtrace@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-dtrace To unsubscribe, send any mail to "freebsd-dtrace-unsubscr...@freebsd.org"
Re: Why can't I dtrace processes running in a jail from the host?
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 : > > 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. ___ freebsd-dtrace@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-dtrace To unsubscribe, send any mail to "freebsd-dtrace-unsubscr...@freebsd.org"
Re: Why can't I dtrace processes running in a jail from the host?
Hi! > Am 09.08.2018 um 16:52 schrieb Mark Johnston : > 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. Any ideas? Thanks Patrick -- punkt.de GmbH Internet - Dienstleistungen - Beratung Kaiserallee 13a Tel.: 0721 9109-0 Fax: -100 76133 Karlsruhe i...@punkt.de http://punkt.de AG Mannheim 108285 Gf: Juergen Egeling ___ freebsd-dtrace@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-dtrace To unsubscribe, send any mail to "freebsd-dtrace-unsubscr...@freebsd.org"
