address@hidden wrote:
I'm on a short vacation now and typing into a crazy old terminal.
Anyway, don't call methods in a signalhandler, its a well known
security hole. Instead set a flag. BTW, good idea using thread join
on the httpd thread *before* calling gc and closing files.. I'll be
back Sunday evening and can take a look at it, but I guess you have
solved it by then :-) Ps. blocking signals in a signal handler is
done (from memory) using SIGIGN at the start og the handler.
Jan-Henrik
OK, i hope that the first reported race condition is fixed. Monit now
waits for httpd to terminate.
With previous behavior, monit http thread blocked on accept => it was
not able to detect stopped flag value until some connection arrived.
Because the timeframe in do_destroy between stopped flag setup,
garbage collection, filedescriptors close and monit exit was very
short, it seems that the race condition occured in major amount of
monit quit attempts. New behavior allows to shutdown monit httpd
gracefully (close sockets, etc.)
---
The second race condition/deadlock is strange. I saw it on Redhat 9,
but i'm not able to replicate it on Debian (unstable). The problem
could maybe occure (just theory) in the case, that monit receives
signal and it is inside do_destroy called from main():
--SNIP--
int main(int argc, char **argv) {
prog= stripfilename(argv[0]);
init_env();
handle_options(argc, argv);
do_init();
do_action(argv);
do_destroy(SIGSTOP);
...
--SNIP--
Because do_destroy() is called directly, it is not protected as signal
handlers are => it can be interrupted probably. Maybe the solution
could be to block signals in main() before do_destroy(). What do you
think?
Martin