Forum OpenACS Q&A: freebsd 5 -current, aolserver 3.4.2, pg 7.2.4, openacs 4.6.3 anyone?

Howdy,

Has anyone got the subject line's configuration up and running?  I'm pretty close, but have some mysterious behaviour.

* even though the debug variable in the config script is set to true (i.e. most things are set to verbose logging), my error log is empty

* I get "OpenACS could not allocate a handle from database pool "pool2"  on the first page.  Database is running, user name is correct, database pools are defined, the driver seemed to compile correctly from the ports collection and is properly defined in the the config script.

Makes ya stop and go "hmm".

As is the norm, I've probably missed one small, but important configuration step.  I've had to use a vulcan mind meld between the 4.6.3 docs and orchardlabs to get things working on FreeBSD, so I might have jumped over something along the way.

Any clues appreciated.  Confirmation that it is possible to get it working with my setup also appreciated.

Thanks,

An update for others that may choose this path...

Both /usr/ports/www/pgdriver (2.0) and /usr/ports/www/nspostrges  (3.0) are out of date and won't work with OpenACS 4.6.3.  I built nspostrges 3.5 by hand with a fair amount of trial and error, serious investigation, and some minor hacking of the Makefile.

The error log isn't exactly empty, just unreadable.  There are lines added to it, but I haven't figured how to read them.  Neither console or remote ssh got me anywhere.

I finally got things running by using the nsd -f foreground mode which allows me to read the error log too.  Haven't managed to get it running in the background yet which makes me think that I have environmental variable in regards to PG set while logged in, that isn't while daemontools starts the process...

I'll post back here with any tips or tricks.  The good news though, is that it can be done.  I've just run through the OpenACS installation process.  The bad news is that it is far from a straight forward process.

Hi Walter,

I haven't tried the full oacs set up, but was able to compile aolserver 4 from sources and run in the background (no -f or -i) without any problems.  It writes to the error log just fine.  I guess you've got the file permissions correct, or you wouldn't see anything, gibberish or otherwise, in your error log.  That would have been my first suggestion.

The only difficultly I have run into is with /etc/ttys.  The docs say that it should work more or less like /etc/inittab on other Unices, but I wasn't able to get it to work.  Daemontools here I come...

The trick with daemontools is the order of how things are started.  Right now on my system daemontool's svcscan is called (and thus my aolserver instance is started) before my pg instance which causes my nsd server not to be able to connect to pg.  As a work around, I've been restarting my nsd server after reboot, so that it gets a chance to connect correctly to pg.

I haven't gotten around to figuring out how to change the startup order for /etc/rc.local (the svcscan call) vs /usr/local/etc/rc.d/010.pgsql.sh (the pg startup script).  Seems obvious that system wide settings under /etc would start before local stuff under /usr/local/etc/rc.d/, but  I haven't had to RTFM to figure out a good work around.

If you get it working in the correct order, let me know.

Thanks,

Walter

Looks like there is is a /usr/local/etc/rc.d/svcscan.sh.sample that might be a better way to go then adding a line in /etc/rc.local...
I found the problem, at least partially.  It seems to be a threading issue.  Are you using libthr?  I set up /etc/libmap.conf to use libthr instead of libc_r.  After I changed to using libc_r, nsd starts up fine in the background.  I haven't yet tried it with libkse, but I'll probably do that later today.
Okay, I just did it.  I set up /etc/libmap.conf like so:
libc_r.so    libkse.so
libc_r.so.5    libkse.so.1

It works fine so far.  Looks like libthr isn't the one to use with aolserver, for now.

Does this specifically fix the error log writing problem?  I'm not able to ssh access my server at the moment, so I can't test it myself.  Just curious.

Thanks,

Yes, for me it does.  I had no log at all before this.
What's the entire process you went through to have /etc/libmap.conf make a difference?

I have my ideas, but you might as well spell it out for posterity.

Thanks,

Well, I had a sneaking suspicion this was a threading issue, because the threading on FreeBSD 5-CURRENT is in a flux right now, with 3 different pthread libraries to choose from:  the legacy libc_r, and two new kernel threading libs, libthr and libkse, which aren't mature yet.

FreeBSD-current now has a feature which allows ld-elf.so to "map" one library to another, so for example programs which are linked against libc_r can be remapped to libthr or libkse (since they all share the same abi), and the place to configure this is /etc/libmap.conf.  You could achieve a similar effect with symlinks, only this is a cleaner solution.

Originally I had libmap.conf set up like so:
libc_r.so        libthr.so
libc_r.so.5      libthr.so.1
(You can also set it to use per-program settings, read the man page for libmap.conf(5)).

I decided to try commenting out both lines in libmap.conf, so that it was not mapping at all but only using the libc_r library.  At that point, all my nsd troubles stopped.  I then decided to try mapping libc_r to libkse instead of libthr.  Everything continued to work.

That is how I came to discover this.  Is it working for you now?

No, but it maybe because I don't have libmap.conf enabled in rtld-elf. libmap.conf's man page says to "see src/libexec/rtld-elf/Makefile" to enable it. /usr/src/libexec/rtld-elf/Makefile has the following:

# add 'WITH_LIBMAP=yes' to /etc/make.conf, recompile
# and reinstall rtld-elf.

I'm going to going to do some digging around before I recompile rtld-elf. I may just use symlinks.

Well, I compiled with libmap.conf support and reinstalled, but still after reboot and restarting of my AOLserver instance via daemontools the error log is acting funny.  Oh well.  Did you you rebuild AOLserver s it uses the correct libs or anything?

Does your run script have any different arguements than "-it"?

Thanks for looking into this,

You know, I just realized you're using aolserver 3.4.2, and I'm using 3.3oacs1 or whatever it's called.  Could that be the difference?  I created a port for it that I could send you if you're interested in trying that.  I actually don't have a run script set up, I've just been doing it by hand with "-t" argument.

Another thing is, how up to date is your current system?  Maybe it should be rebuilt.