Forum OpenACS Q&A: Daemontools disabled error log ... ?

Just setup daemontools on our clients aolservers, so that we can do log file rotation/compression of the error.log files, and I think I followed all the directions properly ... but with switching to daemontools, nothing is being written to the error log file anymore ...

I haven't changed anything in their nsd.tcl files, on setup daemontools and got rid of the FreeBSD aolserver.sh startup file ...

The only change I can see in the server start up is that daemontools requires the -i option for nsd8x, which, from what I can read, is supposed to shoot stdout to the server log file ...

Is there something else that I'm overlooking?  Something that I need to setup in the nsd.tcl file other then the ServerLog ns_param?

Collapse
Posted by Randy O'Meara on
I'm not sure where you want your error log to appear but it works pretty slick if you use the daemontools multilog program to handle it. It rolls at a specified size and you specify how many historical files you want to keep. In this way, you are *guaranteed* that you can control the maximum storage space used. You will *never* have an exhausted filesystem if you set it up this way. Of course, since it's a DJB tool, it's a bit cryptic. But you can work through that if you download and install the separately published man pages for daemontools.

If you have a directory (or symlink to a directory) named 'log' in your service directory (the same location you placed your daemontools 'run' file), and if that log directory contains a file named 'run' that invokes multilog, then 'supervise' (the daemontools daemon that runs and watches *your* daemon) will automatically control the log file process. I previously published an article in these forums that describes a setup using 'multilog'. You can search for that or look at my postings.

A possible setup may look like this:

  • /service/service0 is a symlink to your openacs root (say /home/servers/service0)
  • your openacs root contains a 'run' script [1]
  • your openacs root contains a symlink named 'log' that points to your log directory (say /var/log/aolserver/service0)
  • your log directory contains a 'run' script [2]

Once you're up and running, you can control log rolling manually if you wish by:

    svc -a /service/service0/log

If for some reason your log isn't showing any content, you may have the file descriptors honked, possibly by moving or removing a log directory while there is an active 'supervise' process directing the flow. In that case, you can straighten things out by:

  • remove your service's symlink from /service
  • svc -xd /home/servers/service0/log
  • svc -xd /home/servers/service0
  • recreate your service's symlink in /service
  • 'svscan' should now automagically restart everything

[1] your service 'run' script
#!/bin/sh
export AOLSERVER_HOME=/home/aolserver
exec 2>&1
exec $AOLSERVER_HOME/bin/nsd -fzt \
    /home/servers/service0/openacs4.tcl \
    -u nsadmin -g web

[2] your log 'run' script
#!/bin/sh
exec setuidgid nsadmin multilog s3999999 +* ./error

Good luck.

Randy

Collapse
Posted by Brian Fenton on
What is the line in your run file to start AOLserver? Mine is
exec /apps/aol33/bin/nsd -izkt /apps/aol33/openacs.tcl -u oracle
Collapse
Posted by Randy O'Meara on
The aolserver run file contents are above. See [1].
Collapse
Posted by Brian Fenton on
Sorry Randy, I was asking Marc the question. 😊
Collapse
Posted by Marc Fournier on
exec /usr/local/aolserver/bin/nsd8x -it /usr/local/www/domain/nsd.tcl -u nobody -g nobody 2>&1
Collapse
Posted by Tom Jackson on

I think if you use daemontools you need to use foreground (-f) not installed (-i). I don't think you need the redirects at the end either.

Collapse
Posted by Brian Fenton on
I think the -i is correct but I'm not sure about the redirects.  What happens when you run the "run" command on its own? That should start AOLserver and create log files. It the run command works then it's probably a permissions problem or something with your daemontools setup. If the run command doesn't work, then it's your problem 😉.