9.3.5 failing to compile with dtrace on FreeBSD 10.1

Started by Luca Ferrariover 11 years ago7 messagesgeneral
Jump to latest
#1Luca Ferrari
fluca1978@infinito.it

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]: /messages/by-id/28743.1301771552@sss.pgh.pa.us
The problem I have in compilation is as follows:

gmake[2]https://forums.freebsd.org/threads/dtrace-userland-and-postgresql.22914/#post-129378: 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]https://forums.freebsd.org/threads/dtrace-userland-and-postgresql.22914/#post-129378: *** [utils/probes.h] Error 2
gmake[2]https://forums.freebsd.org/threads/dtrace-userland-and-postgresql.22914/#post-129378: 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]: /messages/by-id/28743.1301771552@sss.pgh.pa.us
[2]: https://forums.freebsd.org/threads/dtrace-userland-and-postgresql.22914/#post-129378

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

#2Vick Khera
vivek@khera.org
In reply to: Luca Ferrari (#1)
Re: 9.3.5 failing to compile with dtrace on FreeBSD 10.1

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.

#3Tom Lane
tgl@sss.pgh.pa.us
In reply to: Luca Ferrari (#1)
Re: 9.3.5 failing to compile with dtrace on FreeBSD 10.1

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

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

#4Luca Ferrari
fluca1978@infinito.it
In reply to: Tom Lane (#3)
Re: 9.3.5 failing to compile with dtrace on FreeBSD 10.1

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

#5Lacey Powers
lacey.leanne@gmail.com
In reply to: Luca Ferrari (#4)
Re: 9.3.5 failing to compile with dtrace on FreeBSD 10.1

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

#6Keith Fiske
keith@omniti.com
In reply to: Lacey Powers (#5)
Re: 9.3.5 failing to compile with dtrace on FreeBSD 10.1

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:

Show quoted text

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

#7Luca Ferrari
fluca1978@infinito.it
In reply to: Keith Fiske (#6)
Re: 9.3.5 failing to compile with dtrace on FreeBSD 10.1

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

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general