On Wed, Jun 26, 2013 at 11:01 AM, Radu Gheorghe <[email protected]>wrote:
> Hello, > > I know the problem of imfile and rotating logs was discussed a million > times now, but I still can't find a comprehensive answer. So please excuse > me for bringing it up again. > > I understand that previous versions of imfile used to monitor the size of > the log and if that went down, assume it was truncated and start monitoring > from the beginning. > > I also understand that this might cause problems if, for example, the app > starts logging like nuts and the size of the log goes up again right after > truncation. Are there other significant issues that I'm missing? > > I don't remember the exact details, but this was very race. I remember that I spent roughly a month debugging the results, and the only cure out of this was disabling this feature, as there was no way to stabilize it (something along the lines of read vs. FS metadata vs don't remember ;)). > Assuming the answer is "no", can't the old functionality be offered as an > option (eg: checkFileSize=yes/no)? There can be a disclaimer there and it > could be "no" by default. I think this would be useful not only to me, but > for other people using Jetty or other apps that don't play nicely with > having their logfiles moved for rotating. > > That's probably an option, especially if I put in that turning it on is know to cause problems. I still guess that some folks will use this as an invitation to file bug reports and especially support customers will eventually come up and require assistance with it - something I really don't like for a feature I know not to work properly (it's really calling for a lot of trouble...). The real cure, I think, is to rewrite imfile so that it uses epoll, which IMHO would remove the core race problem. It's on my list for about 9 month now (3 yrs even as a very low prio item), but I am currently to busy to look at it. Would help if it got sponsored. There is even an incomplete version of an imfile with epoll support doing by someone else inside the forum - if you want to look for that... Rainer > Speaking about my situation, here's where I'm at: > > ########## > Context > ########## > - moving and creating new logfiles makes Jetty stop logging, and sending > HUP to it doesn't do anything. Although this is what imfile seems to > prefer, I'd have to restart Jetty, which creates a downtime I can't afford > - similarly, copying and truncating logfiles confuses rsyslog, do I'd have > to remove the state file and restart rsyslog. Again, a downtime I can't > afford > > ########## > Other possible solutions > ########## > It seems like there are two solutions I can try. They seem nastier than > what I suggest, but might work: > - find a logging library for Jetty that plays nicely with the "create" > method of rotating. If there is such a library, and I'd have to see what > are the implications for our project > - make Jetty log to syslog directly. Again, it's a fuzzy land, because of > the unknown implications, plus I'm not sure how those libraries will play > with large stacktraces (due to size and \n) > - use a different rsyslog daemon for monitoring the files, so I can afford > to restart it > > Thanks and best regards, > Radu > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com/professional-services/ > What's up with rsyslog? Follow https://twitter.com/rgerhards > NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad > of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you > DON'T LIKE THAT. > _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com/professional-services/ What's up with rsyslog? Follow https://twitter.com/rgerhards NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.
