On 12/04/2012 01:45 AM, John P. Rouillard wrote: > > In message > <CAGfjSCM1HsTggaRJ123nBKWz3qwUD+UASqkr=en+_sd+zvo...@mail.gmail.com> , > Risto Vaarandi writes: > >> 2012/12/3 John P. Rouillard<rou...@cs.umb.edu>: >>> 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.
I think the easiest way to get across this problem is not have a signal flag with values 0/1 for SIGINT, but rather a counter which reflects the number of times SIGINT has been received since last signal check. This would allow for setting the correct debug value even when the SEC process is very busy. Also, maybe the actual correction of the debug level can be done inside the signal handler, since it would require one modulus division and addition. kind regards, risto > > -- > -- 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 > Simple-evcorr-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users > ------------------------------------------------------------------------------ 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 Simple-evcorr-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
