Aaron Bannert <[EMAIL PROTECTED]> writes:
> I disagree with this patch. If we are getting failures on locks
> then we have a bug somewhere and I'd rather not see us cover up
> the problem by decreasing the verbosity.
Here is the sequence of events:
1) a thread in child process A is waiting on semaphore
2) graceful restart triggered
3) parent process cleans up the semaphore
4) that thread in child process A gets a failure (EIDRM) from the
semaphore obtain and gracefully brings down other threads in child
process A
Normally in step 4 we'd get a high-severity log message. I changed
the code to set the severity to debug since everything is working as
designed. The process isn't going away prematurely, threads with
active connections have a chance to finish serving the connection,
etc.
A variation on the sequence above is
1) a thread in child process B holds the semaphore and is blocked in
poll()
2) graceful restart triggered
3) parent process cleans up semaphore and wakes up children
4) that thread in child process B returns from poll() and gets a
failure from the semaphore release and tries to gracefully bring
down other threads in child process B
As with the previous scenario, everything is working fine. There is
no sense having a high-priority log message about an expected
condition.
--
Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
