> > So I will pull it in as is and wait for some feedback from the field > > (with the assumption "no feedback" equals "OK"). > hold on, please. There is still some development and we need to make > clear in > one thing. Here it is: > "-g" accepts only gss connections > "-t" accepts all connections (gss as a plain text) > but, we have a requirement to log both(gss and non-gss). > Solutions: > 1. -g somePort -t someOtherPort > - this might be easy implemented > > 2. check if the mesaage is gss or not > - a bit hackish, since there is no protocol > > I think patch is OK to release, but I'd like to avoid breaking > compatibility > in the future.
OK, valid point. Will hold, a few days don't matter, upward compatibility is more important. > > I will then begin to look at the loadable module de-initialization. > This > > is not really clean in the current release, but that's no problem > > because modules never get unloaded. However, in the long term we need > > this to be clean. > > > > The mysterios segfault issue is still dangling. I was hesitant to do > any > > larger-scale new development without fixing it. But given the fact > that > > it is extremely hard to find, and obviously happens very seldom, I'll > > continue developing. I am right now looking into upgrading the dev > > machine to an x64 OS, where most of the problems happened. My hope is > > that I will see a segfault during further development work and then > > hopefully be able to tackle it. I still think that the segfault must > be > > well understood and fixed before I go into some serious > multithreading > > redesign. As such, unfortunately, this issue still holds some of the > > work scheduled for the next *major* version. > > This bug is my nightmare. I really don't know what to do. I run 2 > syslogs in > valgrind during a weekend. Sendind message via UDP on 64 architecture, > messages generated every 1/3sec. RESULT: no segfault. :-( > > F8 is out for 2 weeks, we have only one bug report. I released an > update to > 1.19.10. My nightmare, too. I have hunted a number of bugs, but this one is really the nastiest I have seen in over 20 years :(. You don't see it in lab, and you don't see it in code review. And the worst thing is that I have no clue left what may be the issue - besides that it is related to threading. But the threading model is that simple... Rainer _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog
