On Thu, Apr 14, 2011 at 07:17, Brian Maher <br...@brimworks.com> wrote: > Here are some other random ideas:
> For the log rotation problem I normally write to a named pipe and have > cronolog or multilog read from that named pipe: > http://cronolog.org/ > http://cr.yp.to/daemontools/multilog.html > I also have cronolog or multilog monitored with daemontools's > supervise program or runit's runsv since cronolog will exit if you run > out of disk space (and cause all writers to block which effectively > creates a denial of service). I remember considering this solution a year ago, but I did reject it. Can't remember why though. Anyway, this is not a system solution, but solution for a particular problem. > In general, I use supervise or runsv to > monitor all my daemon's, it is also a much easier interface for > dealing with daemon's in my opinion. That I do as well. > For graceful server shutdown I would agree with other people that > doing it via signals would be easiest. I wish I could! > I don't know enough about > existing Lua signal library implementations, but in general you need > to be careful in C about what functions get executed in your signal > handlers. So for example, libev's signal handling facilities uses the > "self pipe trick" so that your signal handles are ran in the "normal" > flow of the event loop. > Anyways, the easiest thing I can think of to do is to write a simple > Lua C extension that handles SIGHUP and updates a userdata. Then at > the end of your request processing, check the userdata to see if a > signal was received and if so, then exit/respawn. > Of course, the only problem with this solution is that you don't get a > "timely" shutdown since your only checking the state variable at the > end of processing a request. To overcome this, ideally you would > check the accept() system call to see if it errors with EINTR and if > so, then check the userdata to see if we got interrupted because of > our SIGHUP handler and if so, then shutdown immediately. > http://linux.die.net/man/2/accept The problem is that WSAPI does not use luasocket. (At least not in wsapi-fcgi flavor that I use — it uses libfcgi stuff there.) > Unfortunately, it looks like you would need to hack lua sockets for that > though: > https://github.com/LuaDist/luasocket/blob/master/src/usocket.c#L190 That would be really useful for several of my small standalone TCP services. Diego, maybe luasocket can be fixed to accomodate this? Alexander. _______________________________________________ Kepler-Project mailing list Kepler-Project@lists.luaforge.net http://lists.luaforge.net/cgi-bin/mailman/listinfo/kepler-project http://www.keplerproject.org/
