Обсуждение: 9.3.5 failing to compile with dtrace on FreeBSD 10.1
Hi all, I'm trying to compile 9.3.5 from ports on FreeBSD 10.1-release with dtrace enabled. It was a long time ago I looked at dtrace + PostgreSQL + FreeBSD (see [1], [2]), so I'm not updated on how far it got. The problem I have in compilation is as follows: gmake[2]: Entering directory '/mnt/ada1a/ports/databases/postgresql93-server/work/postgresql-9.3.5/src/backend' gmake -C utils probes.h gmake[3]: Entering directory '/mnt/ada1a/ports/databases/postgresql93-server/work/postgresql-9.3.5/src/backend/utils' dtrace -C -h -s probes.d -o probes.h.tmp dtrace: failed to compile script probes.d: "/usr/lib/dtrace/ip.d", line 2: type redeclared: struct devinfo Makefile:38: recipe for target 'probes.h' failed gmake[3]: *** [probes.h] Error 1 gmake[3]: Leaving directory '/mnt/ada1a/ports/databases/postgresql93-server/work/postgresql-9.3.5/src/backend/utils' Makefile:157: recipe for target 'utils/probes.h' failed gmake[2]: *** [utils/probes.h] Error 2 gmake[2]: Leaving directory '/mnt/ada1a/ports/databases/postgresql93-server/work/postgresql-9.3.5/src/backend' *** Error code 2 Am I missing something? Thanks, Luca [1] http://www.postgresql.org/message-id/28743.1301771552@sss.pgh.pa.us [2] https://forums.freebsd.org/threads/dtrace-userland-and-postgresql.22914/#post-129378
On Tue, Dec 16, 2014 at 7:49 AM, Luca Ferrari <fluca1978@infinito.it> wrote:
Am I missing something?
FWIW I tried his a few times, in FreeBSD 9.3 and 10.0 with Pg 9.2 I believe. I've not ever had it build successfully. I don't know why it is an option on the port if it doesn't work. I never filed a bug report because it just wasn't that important to me; it was just a curiosity.
Luca Ferrari <fluca1978@infinito.it> writes: > I'm trying to compile 9.3.5 from ports on FreeBSD 10.1-release with > dtrace enabled. > It was a long time ago I looked at dtrace + PostgreSQL + FreeBSD (see > [1], [2]), so I'm not updated on how far it got. > The problem I have in compilation is as follows: > dtrace -C -h -s probes.d -o probes.h.tmp > dtrace: failed to compile script probes.d: "/usr/lib/dtrace/ip.d", > line 2: type redeclared: struct devinfo > Makefile:38: recipe for target 'probes.h' failed > gmake[3]: *** [probes.h] Error 1 There's nothing about either ip.d or struct devinfo in our probes.d, so this looks like there's something broken about your dtrace installation. Either that or we need to give more/different switches to dtrace to get it to work on FreeBSD. AFAIK, our dtrace support has only really been tested on Solaris and OS X, so it wouldn't be that surprising if more adjustments are needed to make it work elsewhere. If you want to push on this I think you'll need to find a BSD dtrace expert. You shouldn't need to show him/her much except the above dtrace invocation and the probes.d file. regards, tom lane
On Tue, Dec 16, 2014 at 4:06 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > If you want to push on this I think you'll need to find a BSD dtrace > expert. You shouldn't need to show him/her much except the above > dtrace invocation and the probes.d file. > I've filled a bug report and I'll report back here if I get any update on the matter. In the meantime I've tried 9.4 beta and the same issue arises. Luca
Hello Luca, I had some success getting PostgreSQL 9.4 to build on FreeBSD 10.1-p2 RELEASE with DTrace. The probes look fully functional, and fun to work with, though I haven't had time to get incredibly deep into using them.This is what worked for me, after much digging around. I was building and running PostgreSQL and dtrace directly on my workstation, not in a jail. I'm not sure what additional hoops would need to hopped through off-hand to run dtrace on FreeBSD in a jail. Initially, I got compile errors, but I tracked those down and realized that I needed to load the dtrace kernel modules, which I had expected to be loaded automatically, but weren't. Otherwise, you get cryptic compile errors. I had to load the dtrace kernel modules with: kldload dtraceall (and enable it in /boot/loader.conf with dtraceall_load="YES", if you want it to hang around) Add the following lines to your /etc/make.conf (because detailed backtraces are helpful) STRIP= CFLAGS+=-fno-omit-frame-pointer Once that's loaded, change the permissions to 0666 on /dev/dtrace/helper (and add that to /etc/devfs.conf with "perm /dev/dtrace/helper 0666" if you want it to persist) Though be aware that there are security implications for that, since other users could make a ton of probes and exhaust kernel memory. Alternately, you could add pgsql to wheel, since root and wheel are the owner and group for that devfs node. Also be sure to not use devel/libelf from ports, because that doesn't seem to play nice with dtrace, and keeps probes from registering. After doing all that, I could get dtrace to build, link, and register userland probes with the database/postgresql94-server and database/postgresql94-client, and successfully count transaction times in a dtrace script. One final note, the freebsd-dtrace@freebsd.org list, is very helpful with esoteric DTrace issues. I hope this all helps. =) Regards, Lacey > On Tue, Dec 16, 2014 at 4:06 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> If you want to push on this I think you'll need to find a BSD dtrace >> expert. You shouldn't need to show him/her much except the above >> dtrace invocation and the probes.d file. >> > I've filled a bug report and I'll report back here if I get any update > on the matter. > In the meantime I've tried 9.4 beta and the same issue arises. > > Luca > >
Just wanted to thank Lacey for the assistance. I set up my first BSD server recently and installing things via ports had been going great until this.
The docs don't mention how to enable the kernel modules permanently either, so thanks also for that additional note. https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/dtrace-enable.html
Perhaps adding a section on BSD ports and/or expanding on the Dtrace section (15.7.6.6) in this part of the postgresql install docs may be helpful for others?
http://www.postgresql.org/docs/current/static/installation-platform-notes.html
None of the other steps besides the kernel loading are needed for compilation and installation, but could be handy.
On Mon, Dec 22, 2014 at 2:22 PM, Lacey Powers <lacey.leanne@gmail.com> wrote:
Hello Luca,
I had some success getting PostgreSQL 9.4 to build on FreeBSD 10.1-p2 RELEASE with DTrace. The probes look fully functional, and fun to work with, though I haven't had time to get incredibly deep into using them.This is what worked for me, after much digging around.
I was building and running PostgreSQL and dtrace directly on my workstation, not in a jail. I'm not sure what additional hoops would need to hopped through off-hand to run dtrace on FreeBSD in a jail.
Initially, I got compile errors, but I tracked those down and realized that I needed to load the dtrace kernel modules, which I had expected to be loaded automatically, but weren't. Otherwise, you get cryptic compile errors.
I had to load the dtrace kernel modules with:
kldload dtraceall (and enable it in /boot/loader.conf with dtraceall_load="YES", if you want it to hang around)
Add the following lines to your /etc/make.conf (because detailed backtraces are helpful)
STRIP=
CFLAGS+=-fno-omit-frame-pointer
Once that's loaded, change the permissions to 0666 on /dev/dtrace/helper (and add that to /etc/devfs.conf with "perm /dev/dtrace/helper 0666" if you want it to persist)
Though be aware that there are security implications for that, since other users could make a ton of probes and exhaust kernel memory. Alternately, you could add pgsql to wheel, since root and wheel are the owner and group for that devfs node.
Also be sure to not use devel/libelf from ports, because that doesn't seem to play nice with dtrace, and keeps probes from registering.
After doing all that, I could get dtrace to build, link, and register userland probes with the database/postgresql94-server and database/postgresql94-client, and successfully count transaction times in a dtrace script.
One final note, the freebsd-dtrace@freebsd.org list, is very helpful with esoteric DTrace issues.
I hope this all helps. =)
Regards,
LaceyOn Tue, Dec 16, 2014 at 4:06 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:If you want to push on this I think you'll need to find a BSD dtraceI've filled a bug report and I'll report back here if I get any update
expert. You shouldn't need to show him/her much except the above
dtrace invocation and the probes.d file.
on the matter.
In the meantime I've tried 9.4 beta and the same issue arises.
Luca
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Thanks, I'm going to try this solution and report back also to the bug tracker I opened time ago: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196053 Luca On Sat, Jan 24, 2015 at 8:53 AM, Keith Fiske <keith@omniti.com> wrote: > Just wanted to thank Lacey for the assistance. I set up my first BSD server > recently and installing things via ports had been going great until this. > The docs don't mention how to enable the kernel modules permanently either, > so thanks also for that additional note. > https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/dtrace-enable.html > > Perhaps adding a section on BSD ports and/or expanding on the Dtrace section > (15.7.6.6) in this part of the postgresql install docs may be helpful for > others? > http://www.postgresql.org/docs/current/static/installation-platform-notes.html > > None of the other steps besides the kernel loading are needed for > compilation and installation, but could be handy. > > -- > Keith Fiske > Database Administrator > OmniTI Computer Consulting, Inc. > http://www.keithf4.com > > On Mon, Dec 22, 2014 at 2:22 PM, Lacey Powers <lacey.leanne@gmail.com> > wrote: >> >> Hello Luca, >> >> I had some success getting PostgreSQL 9.4 to build on FreeBSD 10.1-p2 >> RELEASE with DTrace. The probes look fully functional, and fun to work with, >> though I haven't had time to get incredibly deep into using them.This is >> what worked for me, after much digging around. >> >> I was building and running PostgreSQL and dtrace directly on my >> workstation, not in a jail. I'm not sure what additional hoops would need to >> hopped through off-hand to run dtrace on FreeBSD in a jail. >> >> Initially, I got compile errors, but I tracked those down and realized >> that I needed to load the dtrace kernel modules, which I had expected to be >> loaded automatically, but weren't. Otherwise, you get cryptic compile >> errors. >> >> I had to load the dtrace kernel modules with: >> >> kldload dtraceall (and enable it in /boot/loader.conf with >> dtraceall_load="YES", if you want it to hang around) >> >> Add the following lines to your /etc/make.conf (because detailed >> backtraces are helpful) >> >> STRIP= >> CFLAGS+=-fno-omit-frame-pointer >> >> Once that's loaded, change the permissions to 0666 on /dev/dtrace/helper >> (and add that to /etc/devfs.conf with "perm /dev/dtrace/helper 0666" if you >> want it to persist) >> >> Though be aware that there are security implications for that, since other >> users could make a ton of probes and exhaust kernel memory. Alternately, you >> could add pgsql to wheel, since root and wheel are the owner and group for >> that devfs node. >> >> Also be sure to not use devel/libelf from ports, because that doesn't seem >> to play nice with dtrace, and keeps probes from registering. >> >> After doing all that, I could get dtrace to build, link, and register >> userland probes with the database/postgresql94-server and >> database/postgresql94-client, and successfully count transaction times in a >> dtrace script. >> >> One final note, the freebsd-dtrace@freebsd.org list, is very helpful with >> esoteric DTrace issues. >> >> I hope this all helps. =) >> >> Regards, >> >> Lacey >> >> >> >>> On Tue, Dec 16, 2014 at 4:06 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >>>> >>>> If you want to push on this I think you'll need to find a BSD dtrace >>>> expert. You shouldn't need to show him/her much except the above >>>> dtrace invocation and the probes.d file. >>>> >>> I've filled a bug report and I'll report back here if I get any update >>> on the matter. >>> In the meantime I've tried 9.4 beta and the same issue arises. >>> >>> Luca >>> >>> >> >> >> >> -- >> Sent via pgsql-general mailing list (pgsql-general@postgresql.org) >> To make changes to your subscription: >> http://www.postgresql.org/mailpref/pgsql-general > >