Forum OpenACS Q&A: Re: AOLserver 4 and daemontools

2: Re: AOLserver 4 and daemontools (response to 1)

Posted by Lachlan Myers on 05/31/04 03:02 AM

Very odd. Here's what works for me - service0 used to protect the guilty :)

#!/bin/sh

exec /usr/local/aolserver/bin/nsd-postgres -it var/lib/aolserver/service0/etc/
service0.tcl -u lach -g web -b service0.net:80,service0.net:443

This should NOT have line breaks in the exec call - I have noticed that its sensitive to *any* line breaks. Using IP dot quad shouldn't cause a problem? The nsd-postgres just sets up the postgres env variables before calling nsd, so that shouldn't change things. I'm using aolserver 4.0 not rc anything.

3: Re: AOLserver 4 and daemontools (response to 2)

Posted by Tom Jackson on 05/31/04 04:12 AM

Could be a permission issue, since it starts up fine as root, or maybe a mismatch between the -b switch and what is in the config file.

OTHO, how did you start/stop it with daemontools? I didn't catch that part.

4: Re: AOLserver 4 and daemontools (response to 3)

Posted by mark dalrymple on 05/31/04 06:28 AM

> OTHO, how did you start/stop it with daemontools? I didn't
> catch that part.

What I have been doing is copying my aolserver4 run file into run, then doing svc -t /service/front-end, which stops the aolserver3 version of the file. I also tried doing an svc -d, waiting for a handful of seconds, then do a svc -u. Also putting in a sleep 30 into run didn't help.

> or maybe a mismatch between the -b switch and what is in the config file.

they're the same. Also tried using the hostname instead of an IP address.

Luckily my web sites are nsvhr'd and are on high ports (don't need -b) and front-end is just my reverse proxy, so I'm not really blocked from getting useful stuff done, but it'd be nice having the same aolserver version for everything.

Wheeee! we having fun yet? 😊

5: Re: AOLserver 4 and daemontools (response to 4)

Posted by Tom Jackson on 05/31/04 07:53 AM

Well one thing: where is the AOLserver log file? svc isn't going to have a log file, unless you set one up, and you need to run AOLserver with -ft to get that to work. An error need to show up somewhere. Even if the -b switch was incorrect AOLserver would still start up just fine, it just wouldn't listen.

Another thing: use -k to kill AOLserver unless you know -t works. If you want it to stop, do a -k and then a -d. You can also test by starting with a -o (once). Either the AOLserver error log or readproctitle will have an error for a restart, unless you have discovered a bug in nsmain. Don't know what would happen then.

I would report it to the AOLserver list, maybe someone else has seen similar behavior.

One more thing: if you are using a high port, why not login as nsadmin and start it up without sudo (./run, and maybe with -ft). Just hoping to expose an error somehow.

6: Re: AOLserver 4 and daemontools (response to 5)

Posted by mark dalrymple on 05/31/04 05:15 PM

> Well one thing: where is the AOLserver log file?

It's in /web/front-end/logs/front-end-error.log. I have a tail -f on that file. When I restart with AS4 plus the -b flag, nothing appears in that file.

> if you are using a high port, why not login as nsadmin and start it up without sudo (./run, and maybe with -ft).

It works fine 😟, stuff appearing in the -error log and it handles requests.

> Either the AOLserver error log or readproctitle will have an error for a restart,
> unless you have discovered a bug in nsmain.

The -error never gets anything written into it when using -b (which seems totally bizarre), without the -b stuff goes to the aolserver log. grepping for readproctitle never shows anything.

Guess it's time to dig into the aolserver source and see what's different in -b land.

8: Re: AOLserver 4 and daemontools (response to 6)

Posted by Tom Jackson on 05/31/04 07:08 PM

Well the error has to be in nsmain I think, since errors are not written to the error log until after all command line params are written and until the config file is read without error. I guess -b does mean bizarre. You could also do a little testing with the -B switch to see what happens. I think it takes the path to a file containing the ip:ports one per line.