I was too quick. I should have said "backported with ease **to v4**". v2 obviously is so outdated, that this will require a totally different effort.
----- Ursprüngliche Nachricht ----- Von: "Rainer Gerhards" <[email protected]> An: "rsyslog-users" <[email protected]> Gesendet: 01.09.09 19:56 Betreff: Re: [rsyslog] Three bugs to stable v2 reported to Red Hat Interesting - as i said, everything works fine under fedora with 2000 connections... Anyhow: going away from select is not trivial, but on my schedule for v5. This functionality can probably be backported with relative ease once it is available. Depending on the bug hunt effort, i'd say within the autumn. rainer ----- Ursprüngliche Nachricht ----- Von: "Tomas Heinrich" <[email protected]> An: "rsyslog-users" <[email protected]> Gesendet: 01.09.09 19:01 Betreff: Re: [rsyslog] Three bugs to stable v2 reported to Red Hat On 08/31/2009 10:00 PM, Rainer Gerhards wrote: >> The limitation of 1000 open file descriptors however (limitation of >> select()) is still there in newer rsyslog releases and >> therefor we are >> probably forced to work around it. Although I find it >> personally strange >> that this limitation is not a more widespread problem. Is >> everybody using >> a database backend ? Or are people segregating syslog messages by >> location/importance ? > > I am not sure tha it is a select() limit. I routinely run tests with 2000 tcp > connections under Fedora and it works well. An issue, of course, is the > per-process file handle limit, which (on many systems) is 1,024. In current > releases, you can simple increase that limit via the $MaxOpenFiles directive: Part of the problem, based on the log excerpt from one of the bug reports, is that the file descriptor limit for the process is too low; Aug 1 19:10:30 lg2log01 rsyslogd:tcp accept, ignoring error and connection request: Too many open files Aug 1 19:10:34 lg2log01 rsyslogd:last message repeated 49 times Aug 1 19:10:33 lg2log01 rsyslogd:tcp accept, ignoring error and connection request: Too many open files This isn't caused by select(). It should be possible to change the limit with 'ulimit -n <nbr>'. The issue with select() remains, though. It has a hardcoded limit on the number of file descriptors of FD_SETSIZE. I've run a test with rsyslog 2.0.6 and I haven't been able to receive messages from tcp clients with fds > 1024. Tomas _______________________________________________ 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 _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com
