In message
<CAGfjSCM1HsTggaRJ123nBKWz3qwUD+UASqkr=en+_sd+zvo...@mail.gmail.com> ,
Risto Vaarandi writes:

>2012/12/3 John P. Rouillard <[email protected]>:
>> One of the nice things about SIGINT handiling when sec is running as a
>> daemon is that you can increase debugging.
>> One of the bad things is that it increments and wraps the debug value.
>> Once you wrap to 1 you don't see any more indications of the debug
>> level incrementing until you get to level 5 or 6.
>> On a very busy SEC process, a signal can get lost. So sending 4 kill
>> -INT to a sec process only delivers 2.
>
>Just out of curiosity, why are signals getting lost? The reception of
>each signal sets a flag which is checked after each iteration over
>input lines. So this condition should not happen, unless processing of
>some input line takes so long that there is sufficient time to send
>the signal twice.

Yup, I think that is exactly what's happening. It only happens under
heavy load (50% cpu use 500 events/sec inbound). I send a signal, up
arrow, send the signal again, up arrow... till I sent 4 of them to get
it back to debug level 4 (from debug level 6).

I think this is probably the only time when you would send multiple
repeat signals since you are incrementing a counter rather than having
it actually reload/dump data etc.

--
                                -- rouilj
John Rouillard
===========================================================================
My employers don't acknowledge my existence much less my opinions.

------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
_______________________________________________
Simple-evcorr-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users

Reply via email to