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.
