Hi David, thanks for this note, but I think it is not related to the fix (I'll think a bit harder about that, but so far I can not find any connection between the two).
The way the HUP is done is sub-optimal. Under typical load (one hup a day), you don't see any issue. If you hup very frequently (like the once a min you do) and have heavy traffic, that's another story. To solve that case, some rework on the hup internals, actually even on the interface definition, is needed. I'd hold all such work unless I found a solution to the race bug - because it would have made the environment even more different. Now that I have at least one issue, I think I can go ahead and begin to introduce more intrusive changes again. In any case, I'll have a more in-depth look at the hup handlers. The new non-restart type of hup should be almost resistant against the issue you report. Rainer On Thu, 2009-01-29 at 20:56 -0800, [email protected] wrote: > On Thu, 29 Jan 2009, Rainer Gerhards wrote: > > >> > >> congradulations on tracking down a nasty and subtle issue. > > > > Thanks - but let's first see if this was the only issue and if things > > run smooth everywhere. But it looks very promising. > > > > bad news, on my system the HUP doesn't always reopen the files now. > > high speed box receiving messages via UDP, idle except for a gzip > compressing the files (which are rotated once a min), the system runs fine > for a few min (higher performance than before, it's now writing ~93,000 > messages/sec instead of ~78,000 messages/sec), but it sometimes mangles > handling a HUP and gets stuck. I have to do a kill -9 to kill and restart > it. > > this is with the new HUP behavior. > > David Lang > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com
