Will do as soon as I can get to it. Was short of merging today before more urgent things came in :(
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.
