> -----Original Message----- > From: Michael Biebl [mailto:bi...@debian.org] > Sent: Sunday, March 13, 2011 11:22 AM > To: Phil Dibowitz; 617...@bugs.debian.org; Rainer Gerhards > Cc: cont...@bugs.debian.org > Subject: Re: Bug#617996: rsyslog: remote syslog messages not logged > > retitle 617996 remote syslog broken on kernels without epoll support > severity 617996 normal > thanks > > Am 13.03.2011 11:06, schrieb Phil Dibowitz: > > On 03/13/2011 01:51 AM, Michael Biebl wrote: > >>> Ever since the 5.7 upgrade which I installed on 2/20, my rsyslog > hasn't been > >>> logging messages from remote sources. This started on the 5.7.4-1 > package and > >>> has continued with 5.7.4-2, 5.7.5-1, 5.7.6-1, and 5.7.8-1. > >> > >> Just to clarify this: What was the last version that you tested and > that worked > >> for you? > > > > The machine runs sid and does an 'apt-get update && apt-get upgrade' > every > > night. The last version that worked from the dpkg logs was 4.6.4-2. > > > >> According to the upstream changelog, epoll support in the netstream > drivers was > >> implemented in 5.5.1, the first v5 version shipped in Debian was > 5.7.1-1 > > > > That would make sense, sid skipped straight from 4.6.x to 5.7.x, > afaict. > > > > OK, machine just finished rebooting - looks like that fixed it. > Thanks! > > So, a combination of lenny kernel + wheezy rsyslog is not correctly > working, > whereas squeeze kernel + wheezy rsyslog will. > 2-releases old kernels are not really supported in Debian, we do our > best to > support the kernel from the last release. > > That said, it is still a bug, but I downgraded it to normal and > retitled it. > > Rainer, the epoll usage in rsyslog should apply runtime checks when > using epoll > and fall back gracefully. the following was suggested in a similar > situation [1]:
Mmmhhhh... Is that really something we need to support? I can think of many other places where the code relies on the outcome of configure. If I need to redo all (well: some of) the configure checks at runtime, the codebase gets really complicated and probably hard to maintain. So far, I assumed that the configure checks are sufficient to build the code. Wouldn't it then be better to just disable epoll support in the regularly distributed version and only have it activated for folks that build the code for a specific environment? That sounds much more clean to me (it has a price, of course, but if we want to support very old systems at all costs, we need to pay a price...). Rainer -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
