Re: Filter out dtrace(1) probes
Hi Farhan:
I'm not sure what the question is, but by what I understood it sounds like a
predicate with probefunc should do?
i.e.:
prov:mod:func:name
/probefunc != "something_i_dont_care_about"/
{
something_here
}
—
Domagoj
> On 17 Aug 2018, at 00:49, Farhan Khan wrote:
>
> Hi all,
>
> Is it possible to filter out probes?
> For example, if I did:
>
> dtrace -n 'fbt:kernel::entry { something_here }'
>
> but I specifically do not want fbt:entry:SOMETHING:entry, is that
> possible? I know that I can run grep -v, but it still shows the output
> from "something_here".
>
> Thank you,
> --
> Farhan Khan
> PGP Fingerprint: B28D 2726 E2BC A97E 3854 5ABE 9A9F 00BC D525 16EE
> ___
> 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"
signature.asc
Description: Message signed with OpenPGP
Filter out dtrace(1) probes
Hi all,
Is it possible to filter out probes?
For example, if I did:
dtrace -n 'fbt:kernel::entry { something_here }'
but I specifically do not want fbt:entry:SOMETHING:entry, is that
possible? I know that I can run grep -v, but it still shows the output
from "something_here".
Thank you,
--
Farhan Khan
PGP Fingerprint: B28D 2726 E2BC A97E 3854 5ABE 9A9F 00BC D525 16EE
___
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?
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"
