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.
...as it turns out, the perl signal handling was changed in perl 5.8, and it is possible that if a signal is repeated within very short time, it is ignored by perl. Internally, perl postpones the execution of the signal handler to a moment when it is safe to do so. However, during postponing the flag approach is used inside perl, not counter. Therefore, the handler is executed only once if the flag was already set before the second signal arrived. Although it seems it is not possible to entirely avoid the "lost signal problem" due to internals of perl, I've switched the SEC code from flag approach to counter-based handling. Also, it seemed to me that a message about changed logging verbosity could be logged as "severity-less" message -- it would always appear in SEC's textual log file, but it would be logged as a notice-level message into syslog. with 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
