Postgresql provider no longer working

Sevan / Venture37 venture37 at gmail.com
Wed Jun 4 10:35:16 UTC 2014


On 4 June 2014 02:45, Mark Johnston <markj at freebsd.org> 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


More information about the freebsd-dtrace mailing list