On 4 June 2014 02:45, Mark Johnston <[email protected]> wrote: > Hi, > > I can't reproduce this using postgres 9.3.4 on r267033 (current). As > usual, it was necessary to first kldload dtraceall and make sure > postgres could access /dev/dtrace/helper (in my case I've added the > pgsql user to the wheel group). It's also necessary to build with > dtraceall loaded (otherwise dtrace -G will fail I think). With that, > the probes show up as expected. > > Do other ports create probes successfully? lang/php5 has a DTrace > option and manages to create probes when I run it. If it doesn't in > your environment, could you try running it with the > DTRACE_DOF_INIT_DEBUG environment variable set to "1" and pass along > the output? > > Thanks, > -Mark
Hi Mark, As previous, adjusting the permissions on /dev/dtrace/helper resolved the issue. What threw me was that I did try PHP & netatalk before posting & the probes for those two did appear. Revisiting those again now I see that they have a master process which runs as root hence not being locked out of access to /dev/dtrace/helper. Moving forward, what's your opinion on the adition of a new system group called dtrace, & the devfs rules own dtrace/helper root:dtrace perm dtrace/helper 0660 Postgresql can be made a member of this group if it's installed with dtrace support & things work from the start. Happy to raise the patch, just running it past you as I'm unsure what ideas there are for delegating access in the future. Sorry about the false alarm. Sevan / Venture37 _______________________________________________ [email protected] mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-dtrace To unsubscribe, send any mail to "[email protected]"
