THX! Sent from phone, thus brief. Am 26.05.2015 22:08 schrieb "Rainer Gerhards" <[email protected]>:
> A github issue tracker would be useful if you have a moment... > > Sent from phone, thus brief. > Am 26.05.2015 22:05 schrieb "Alexandre Fenyo" <[email protected]>: > >> >> Hi, >> >> I've made some searches and discovered that the same issue had been >> reported one year and a half ago on this rsyslog-users list (see message >> archive here: >> http://lists.adiscon.net/pipermail/rsyslog/2013-December/035237.html) >> and even already encountered 6 months before, during may 2013, as explained >> in the message from jbondc at openmv.com (see original report about this >> problem here: >> http://kb.monitorware.com/high-cpu-usage-after-reboot-freebsd-t11973.html >> ): >> >> > jbondc at openmv.com >> > Wed Dec 11 02:49:22 CET 2013 >> [...] >> > When running in a VM: >> > root at freebsd:/usr/home/jbondc # rsyslogd -v >> [...] >> > I get 100% CPU usage on every boot, same issue as here: >> > >> http://kb.monitorware.com/high-cpu-usage-after-reboot-freebsd-t11973.html >> > >> > Both on FreeBSD 9.2-RELEASE, and FreeBSD 10-BETA3 >> > >> > It looks like an issue with /dev/console and rsyslogd, this fixes it: >> > #*.err;kern.warning;auth.notice;mail.crit /dev/console >> > >> > I broke it down to: >> > kern.warning;auth.notice;mail.crit /dev/console >> > *.err >> /var/log/err.log >> > >> > root at freebsd:/usr/home/jbondc # vi /var/log/err.log >> > 2013-12-10T20:40:29.152512-05:00 freebsd rsyslogd: imudp: cannot set >> thread scheduling policy, pthread_setschedparam() not available >> > >> > So it looks like rsyslogd tries to write that message as it loads to >> /dev/console and it goes nuts >> >> So, I think the explanation and the patch I've sent recently could >> definitively solve this problem. >> Could you please have a look at it and tell me if it could be included in >> the main source stream ? >> >> Many thanks, >> Sincerely, >> >> 2015-05-24 20:26 GMT+02:00 Charlie Root <[email protected]>: >> > >> > Hi, >> > >> > Here is a bug report about rsyslog. A patch is attached to correct >> this bug. >> > It occurs only on FreeBSD. I've already sent a bug report on the >> FreeBSD reporting tool: >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200429 >> > >> > I'm sending this mail on this list for the patch to be included in >> the mainstream distribution of rsyslog. >> > >> > Here is the description of the bug: >> > When rsyslog is started at boot time on FreeBSD (by means of rc >> scripts or /etc/rc.local), and when rsyslog is simultaneously configured to >> output some streams to "/dev/console", the daemon will start correctly but, >> at the near end of the boot sequence of FreeBSD, it will fail permanently, >> in an endless loop, using 100% CPU. >> > >> > Attached to this bug report, please find a patch to correct this >> behaviour. >> > >> > Here is a complete explanation of the steps that make the bug >> happen: >> > >> > 1- when init launches rc scripts, rsyslogd starts >> > >> > 2- rsyslogd reads rsyslog.conf and if some stuff must be logged to >> the console, because of a line like >> "*.err;kern.warning;auth.notice;mail.crit /dev/console" in the >> configuration file, the daemon calls open to get a file descriptor to write >> on "/dev/console". It starts writing corresponding logs to this descriptor. >> > >> > 3- Later during the boot sequence, init configures the console, and >> for this to be done, it starts by calling the revoke syscall: >> revoke("/dev/console"). >> > >> > 4- Once /dev/console is revoked, further writes to any file >> descriptor previously opened on this file return -1 with ENXIO as errno, >> even if this descriptor was opened in another process than init. >> > >> > 5- thus, rsyslogd gets this error in >> runtime/stream.c:doWriteCall(), and calls runtime/stream.c:tryTTYRecover() >> since the error occured on a tty. >> > >> > 6- but runtime/stream.c:tryTTYRecover() tries to reopen the tty >> only if the error is EIO on Linux or EBADF on any other operating system. >> Since the error is ENXIO, that is distinct from EBADF, >> runtime/stream.c:tryTTYRecover() returns RS_RET_OK and >> runtime/stream.c:doWriteCall() loops, endlessly. >> > >> > Sincerely, >> >> >> _______________________________________________ >> 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.
