Forum OpenACS Q&A: aolserver running crazy...

Posted by David Kuczek on
A weird thing happend to my aolserver after I restarted it. But my
site is still working although it shows that the postgres driver
couldn't be loaded. Did this happen to anyone else - and why?

    Error: dbdrv: failed to load driver 'postgres'

    Error: dbinit: no such default pool 'main'
    Notice: adp: mapped /*.adp

    Error: nscp: could not listen on

    Error: modload: failed to load '/home/aolserver/bin/':
'Ns_ModuleInit' returned -1

Posted by Connie Hentosh on
I don't know how the site could still be working.... but your first error there refers to the config file for aolserver. View your Aolserver config file (possibly named nsd.tcl) and check your

  ns_section "ns/db/drivers"
	ns_param postgres  
And make sure the path to your postgres driver is correct. Should be something like
Which would mean your file is something like
Posted by David Kuczek on
Hello Connie,

my nsd.tcl says:
ns_section "ns/db/drivers"
ns_param postgres ${bindir}/ ;# Load PostgreSQL

and the is inside /aolserver/bin too.... It worked well until today.

I was messing around with shared memory because on it says:

The default shared memory limit (both SHMMAX and SHMALL) is 32 MB in 2.2 kernels, but it can be changed in the proc file system (without reboot). For example, to allow 128 MB:
$ echo 134217728 >/proc/sys/kernel/shmall
$ echo 134217728 >/proc/sys/kernel/shmmax

after that I started postgres with a 8000 -B flag and it worked. It even appeared to be quite quick. With ipcs I saw that 64mb were allocated to postgres.

But somehow my aolserver doesn't find this funny at all...
Posted by David Kuczek on
oh lord,

the server log is showing this not only once but around five times in a row...

Every five minutes this spectacle finds a repetition...

I wouldn't like to be aolserver now...

Posted by Jonathan Marsden on
Did you restart PG without first stopping AOLserver??

I'd suggest you stop AOLserver, and check with ps that you have no
instances of nsd running.  Then restart PG.  Then start AOLserver and
see if that solves your weirdness.

If not, I'd it's time to back out the changes you made regarding
shared memory...

Posted by David Kuczek on
This is weird. The error that came up first when I started aolserver after I started postgres was:

" cannot open shared object file"

so I read through Don's docs and found

"If you are running PG 7, make a symbolic link from pointing to because AOLserver looks for when loading the driver:

cd /usr/local/pgsql/lib
ln -s (as user postgres)

but I couldn't creat the link as user postgres (no permission) so I just created it as root. Now it works again...

But why did it work yesterday? Did anyone stole that link 😊? no really? And why do I have to set the link as user postgres?
Posted by David Kuczek on
Hello Girodano?! 😊

I deleted your email from my mail account after I read it, because I thought that you also posted it on the site. But well... I didn't rightly remember your name and it sounded like "Giordano Bruno 😊"

For Jonathan - Yes I restarted after stoping it. I suppose from your question that this wasn't quite right...

For Giordano Bruno 😊 - No I didn't test anything with the tool that you wrote about. Maybe you could post your answer on the bboard and specify it a bit more


Posted by Jonathan Marsden on
It's good that the link to the library solved the issue for you.

I'd say it doesn't matter whether root or postgres creates the symlink. If postgres should normally be the owner of /usr/local/pqsql/lib directory ... then postgres should have been able to create that symlink. And it's always safer to have people do things as a non-root user. I'm guessing that is why Don's instructions said do it as postgres. Doing it as root won't break anything.

Posted by Pascal Scheffers on
If postgres should normally be the owner of /usr/local/pqsql/lib directory ... then postgres should have been able to create that symlink.

Please don't do that. Postgres should NOT be the owner of the binaries or the source. The only thing the postgres user may own is it's .../data directory and the datafiles therein. If you carefully examine your installation, you will find that it is quite rare for a service (running with a UID other than root) to also own the binaries. The reason is simple: If a service has been cracked, it will not be able to change it's own binaries to install trojans.