Re: [naviserver-devel] log rolled every time Naviserver shuts down
Dear Andrew,
i've looked into the problem and addressed it in the tip branch.
Here is my understanding: Background:
AOLserver supports just 2 types of signals, namely TERM and HUP
#define NS_SIGTERM 1
#define NS_SIGHUP 2
NaviServer has extended this to the following set of signals
# define NS_SIGHUP 1
# define NS_SIGINT 2
# define NS_SIGQUIT 3
# define NS_SIGPIPE13
# define NS_SIGTERM15
As far as i can see, everything is fine in NaviServer on the unix side.
However, this extension is/was not fully handled on the windows side.
Windows does not support sets of signals (sigset_t + supporting API),
so it uses an approach based on a global variable sigpending,
in which incoming signals are or-ed together. Later the code
checks, whether the signal in question was fired (maybe among
other signals) by testing the bits:
if ((sig NS_SIGHUP)) {
NsRunSignalProcs();
}
This works fine, as long one has just distinct bits (like in
SIGTERM and SIGHUP in aolserver), but in NaviServer this
does not work. From the bit-patterns, SIGQUIT looks like SIGHUP
and SIGINT, one gets false positives on Ctr-c, which is handled
somewhat strangely via NS_SIGTERM from the ConsoleHandler(),
containing the HUP bit, rather than SIGINT.
I've changed the code by using distinct bit-patterns for signal
detection which should address the problem, but have just
checked that the changes compile correctly under windows.
However, i've not located the code, where SIGHUP is handled
on the windows side. Andrew, how do you send SIGHUP to nsd?
-g
Am 28.10.14 01:05, schrieb Andrew Piskorski:
At least on Windows (I have checked this behavior on Linux), when I
start Naviserver in a Command Shell and then shut it down by hitting
Ctrl-c, it rolls both the error and access logs (e.g. renaming
myserver-error.log to myserver-error.log.000).
That's strange, and not what I expect or want. I want to roll logs
only at certain times of day, not every time I restart the server.
That roll-on-shutdown behavior goes away if I set these parameters:
ns_section ns/parameters
ns_param LogRoll false
ns_section ns/server/my_server/module/nslog
ns_param RollOnSignal false
But I expect that will interfere with scheduled log rolling as well.
I WOULD like to roll the logs on SIGHUP, just not every time the
server shuts down. Any idea why the two seem to be conflated?
Is Windows actually sending a HUP signal when I hit Ctrl-c? (I don't
THINK so.) Or is Navisever somehow misinterpreting whatever Windows
does as SIGHUP?
This is a very minor problem but I do wonder just what is going on there.
(Thanks!)
--
___
naviserver-devel mailing list
naviserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/naviserver-devel
Re: [naviserver-devel] 'nsv_unset myarray' fails to unset the array
On Thu, Oct 30, 2014 at 06:45:20PM +0100, Gustaf Neumann wrote: I agree that the array should be gone after the call of nsv_unset a. The behavior is now fixed in the tip branch on bitbucket. Excellent, thank you, Gustaf! I earlier tried some simpler changes in my sandbox (essentially the approach used in AOLserver 4.0.10), which crashed the server. Your fix definitely works, but is more complicated than I expected. When you get a chance, can you say a bit more about how it works? E.g., what is the clientData for exactly, and why do some functions need to use it but others do not? Before calling Tcl_DeleteHashTable() to remove the nsv array, you do something interesting with BucketIndex() and an extra round of locking. Is that due to some new feature that AOLserver did not have, maybe the mutex timings? -- Andrew Piskorski a...@piskorski.com -- ___ naviserver-devel mailing list naviserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/naviserver-devel
Re: [naviserver-devel] log rolled every time Naviserver shuts down
On Sun, Nov 02, 2014 at 01:38:37PM +0100, Gustaf Neumann wrote: I've changed the code by using distinct bit-patterns for signal detection which should address the problem, but have just checked that the changes compile correctly under windows. That seems to fix the excess rolling problem on Windows, thanks! However, i've not located the code, where SIGHUP is handled on the windows side. Andrew, how do you send SIGHUP to nsd? The Windows SIGHUP handling is in NsHandleSignals() in nsd/nswin32.c, which you just fixed, right? Hm, how come NsSendSignal() only supports NS_SIGTERM, NS_SIGINT, and NS_SIGHUP, with no support for NS_SIGQUIT and NS_SIGPIPE ? Andrew, how do you send SIGHUP to nsd? In the distant past on either Linux or Solaris, I think I used an external shell script to send an external SIGHUP to the nsd process, but I never do that anymore. On Windows, the only way I've ever done it is by explicitly calling ns_logroll from the nsd process itself, typically in a scheduled procedure. In nsd/log.c, LogOpen() uses Ns_RegisterAtSignal() with Ns_LogRoll() for handling an incoming SIGHUP. But, the ns_logroll Tcl command simply explicitly calls Ns_LogRoll(), so I don't think it exercises the signal-handling machinery at all. Btw, I just got a copy of this book and read some of it: http://www.amazon.com/gp/product/0321657748/ Windows System Programming, 4th Edition; by Johnson M. Hart published Feb. 2010; ISBN-13: 978-0321657749 It seems pretty good, and has some useful compare/contrast discussion of Windows vs. POSIX thread synchronization APIs. Instead of Unix signals, Windows uses Console Control Handlers or Exceptions (depending on what you're trying to do). Naviserver uses a Console Control Handler. -- Andrew Piskorski a...@piskorski.com -- ___ naviserver-devel mailing list naviserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/naviserver-devel
Re: [naviserver-devel] more logging problems on Windows
On Sun, Nov 02, 2014 at 10:27:21PM -0500, Andrew Piskorski wrote: Two, calling ns_logroll crashed Naviserver with this error: Debug Assertion Failed! f:\dd\vctools\crt_bld\self_x86\crt\src\write.c Line: 68 Expression: (_osfile(fh) FOPEN) Once the nsd debug symbols were working, that one turned out to be an easy fix. All it took was moving the call to Ns_Log() AFTER LogOpen() rather than before it. Done here: https://bitbucket.org/apiskors/naviserver/commits/8d3c79974f084d074f44a9169be75bfa2c5f86bd -- Andrew Piskorski a...@piskorski.com -- ___ naviserver-devel mailing list naviserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/naviserver-devel
