Re: Building Asterisk with PostgreSQL support

[Mike Bowie <mbowie%rocketspace.com@localhost>]

On 6/21/15 7:16 AM, D'Arcy J.M. Cain wrote:
> Interesting.  Asterisk says that "--with-postgres" takes an
> argument which is the directory where PG is installed.  That's why I
> made it "CONFIGURE_ARGS+= --with-postgres=${PREFIX}" in my attempt.

For better or worse, I only tend to include the parameter value if the 
configure script doesn't locating handle it, or requires it explicitly. 
If it does hinge on the parameter specifically for pgsql, I think that 
I've been using PGSQL_PREFIX from mk/pgsql.buildlink3.mk. (I forget the 
case where PREFIX broke for me, but I'm sure I can dig it up if you're 
interested.)

> I haven't actually seen that.  However, the system randomly stops
> running with no core dump even with the -g option.  I am hoping to
> create a developer version that I can install on a test box so that I
> can run the unit tests.  Currently I monitor it every minute and restart
> it if it is down.  It happens maybe once a week on average.  It used to
> be worse before I set up an intrusion detection system and blocked
> attacks on the server.  The attacks never succeeded but they used up a
> lot of resources.

Using -g from the rc.subr init wasn't something I was able to get sorted 
either. I'm somewhat unclear on what $(pwd) is at init time, and since 
the asterisk user requires write access to that path to write core, it 
will just vanish... and frankly, looked to me like a clean shutdown. 
(Grrrr) I manually started it in /var/asterisk in order to get my dumps 
successfully.

The problem you describe sounds more like the second issue I mentioned. 
The first results in active calls being dropped and such as file handles 
for the process are exhausted. (Munging around with ulimit wasn't a 
meaningful success... but that would only have treated the symptom 
anyway.) I too ran a little while; wait; check; script, but ultimately 
backing out that PJ RTP code sorted it for me.

In order to get DONT_OPTIMIZE into the * build, I added an option for 
debug to my options.mk. For a little while, I futzed around with trying 
to get bfd in there too, but that proved to be more complex than my 
little mind could get around. (I've left my attempts at that in there 
for your amusement.) If you are seeing the second issue, you'll see the 
calls end up somewhere in the PJ code, but since it seems to have some 
other magic to include symbols, the exact call is still masked. Perhaps 
you'll have more persistence than I did. ;-)

I had grandiose plans of firing up SIPP on staging to get crazy with 
tests etc... but Day Job(tm) has kept me focused elsewhere.

Best,

Mike.

--- options.mk.orig	2015-06-21 13:40:39.000000000 -0700
+++ options.mk	2015-05-07 06:59:59.000000000 -0700
@@ -2,7 +2,7 @@
 
 PKG_OPTIONS_VAR=		PKG_OPTIONS.asterisk
 PKG_SUPPORTED_OPTIONS=		zaptel x11 unixodbc ilbc webvmail ldap spandsp
-PKG_SUPPORTED_OPTIONS+=		jabber speex pgsql snmp
+PKG_SUPPORTED_OPTIONS+=		jabber speex pgsql snmp debug
 PKG_OPTIONS_LEGACY_OPTS+=	gtk:x11
 PKG_SUGGESTED_OPTIONS=		ldap jabber speex
 
@@ -59,8 +59,22 @@
 CONFIGURE_ARGS+=	--without-iksemel
 .endif
 
+.if !empty(PKG_OPTIONS:Mdebug)
+#DEPENDS+=		gdb-[0-9]*:../../devel/gdb
+# DONT_OPTIMIZE won't stick without --enable-dev-mode
+CONFIGURE_ARGS+=	--enable-dev-mode
+ASTCFLAGS+=		-Wno-unknown-warning-option -Wno-error
+# We need dlopen to work for bfd
+#CFLAGS.NetBSD+=		-D_NETBSD_SOURCE
+# Would be ideal to support libbfd, and therefore BETTER_BACKTRACES at some point
+#CONFIGURE_ARGS+=	--with-bfd=${PREFIX}
+.endif
+
 MAKE_FLAGS+=	GLOBAL_MAKEOPTS=${WRKSRC}/pkgsrc.makeopts
 post-configure:
+.if !empty(PKG_OPTIONS:Mdebug)
+	${ECHO} "MENUSELECT_CFLAGS=DONT_OPTIMIZE DEBUG_THREADS" >> ${WRKSRC}/pkgsrc.makeopts
+.endif
 .if !empty(PKG_OPTIONS:Mx11)
 	${ECHO} "MENUSELECT_PBX=-pbx_gtkconsole" >> ${WRKSRC}/pkgsrc.makeopts
 .endif