Re: Early use of log() does not end up in kernel msg buffer
In message <16486425.yxjbenq...@ralph.baldwin.cx>, John Baldwin writes: >To be clear, you didn't turn off printing to the console, you turned off >writing to the msglog. I've scavenged my notes and can't find anything to explain why. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Early use of log() does not end up in kernel msg buffer
On Monday, April 06, 2015 09:11:21 PM Poul-Henning Kamp wrote: > > In message <2033248.eu3rhs8...@ralph.baldwin.cx>, John Baldwin writes: > > >I think phk@ broke this back in 70239. Before that the log() function did > >this: > > > >log() > >{ > > > > /* log to the msg buffer */ > > kvprintf(fmt, msglogchar, ...); > > > > if (!log_open) { > > /* log to console */ > > kvprintf(fmt, putchar, ...); > > } > >} > > > >I think your patch is fine unless phk@ (cc'd) has a reason for not wanting to > >do this. > > The reason was systems not running syslog having slow serial consoles. To be clear, you didn't turn off printing to the console, you turned off writing to the msglog. That is, before your change: - If syslog wasn't running, the message was sent to the msglog (so that a subsequently started syslog would see it) and to the console. - If syslog was running, the message was only sent to the msglog, but not the console. After your change: - If syslog isn't running, the message is only sent to the console. - If syslog is running, the message is only sent to the msglog. The direct result is that less data is sent to the msglog. Is the concern that when syslogd starts up any pre-boot log messages can be sent over the console a second time by the syslogd process writing to /dev/console? Note that this does mean that any messages logged before syslogd are lost and cannot be accessed by any software on the box that wants to do parse syslogd output, etc. (which is what is probably causing problems for the OP). -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Early use of log() does not end up in kernel msg buffer
In message <552326a2.5000...@badgerio.us>, Eric Badger writes: >> The reason was systems not running syslog having slow serial consoles. > >Correct me if I've misunderstood, but that doesn't seem to matter here; >the proposed change adds logging to the message buffer but leaves >logging to the console (when no syslog is listening) unchanged. Sorry, I must have misunderstood the question then. I don't think I have any opinion on the log() function. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Early use of log() does not end up in kernel msg buffer
On 04/06/2015 04:11 PM, Poul-Henning Kamp wrote: In message <2033248.eu3rhs8...@ralph.baldwin.cx>, John Baldwin writes: I think phk@ broke this back in 70239. Before that the log() function did this: log() { /* log to the msg buffer */ kvprintf(fmt, msglogchar, ...); if (!log_open) { /* log to console */ kvprintf(fmt, putchar, ...); } } I think your patch is fine unless phk@ (cc'd) has a reason for not wanting to do this. The reason was systems not running syslog having slow serial consoles. Correct me if I've misunderstood, but that doesn't seem to matter here; the proposed change adds logging to the message buffer but leaves logging to the console (when no syslog is listening) unchanged. Eric ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Early use of log() does not end up in kernel msg buffer
On 6 April 2015 at 14:11, Poul-Henning Kamp wrote: > > In message <2033248.eu3rhs8...@ralph.baldwin.cx>, John Baldwin writes: > >>I think phk@ broke this back in 70239. Before that the log() function did >>this: >> >>log() >>{ >> >> /* log to the msg buffer */ >> kvprintf(fmt, msglogchar, ...); >> >> if (!log_open) { >> /* log to console */ >> kvprintf(fmt, putchar, ...); >> } >>} >> >>I think your patch is fine unless phk@ (cc'd) has a reason for not wanting to >>do this. > > The reason was systems not running syslog having slow serial consoles. .. and that's still a thing, btw. -adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Early use of log() does not end up in kernel msg buffer
In message <2033248.eu3rhs8...@ralph.baldwin.cx>, John Baldwin writes: >I think phk@ broke this back in 70239. Before that the log() function did >this: > >log() >{ > > /* log to the msg buffer */ > kvprintf(fmt, msglogchar, ...); > > if (!log_open) { > /* log to console */ > kvprintf(fmt, putchar, ...); > } >} > >I think your patch is fine unless phk@ (cc'd) has a reason for not wanting to >do this. The reason was systems not running syslog having slow serial consoles. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Early use of log() does not end up in kernel msg buffer
On Thursday, March 26, 2015 10:20:13 PM Eric Badger wrote: > Using log(9) when no process is reading the log results in the message > going only to the console (contrast with printf(9), which goes to the > console and to the kernel message buffer in this case). I believe it is > truer to the semantics of logging for messages to *always* go to the > message buffer (where they can eventually be collected and in fact put > into a logfile). I therefore propose the attached patch, which sends > log(9) to the message buffer always, and to the console only if no one > has yet opened the log. > > It may be more complete to log to the console only if the log level is > greater than some (user defined) value, but this seems like that might > be more than necessary for this case. > > Thoughts? I think phk@ broke this back in 70239. Before that the log() function did this: log() { /* log to the msg buffer */ kvprintf(fmt, msglogchar, ...); if (!log_open) { /* log to console */ kvprintf(fmt, putchar, ...); } } I think your patch is fine unless phk@ (cc'd) has a reason for not wanting to do this. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Early use of log() does not end up in kernel msg buffer
On 03/26/2015 23:20, Eric Badger wrote: > Using log(9) when no process is reading the log results in the message > going only to the console (contrast with printf(9), which goes to the > console and to the kernel message buffer in this case). I believe it is > truer to the semantics of logging for messages to *always* go to the > message buffer (where they can eventually be collected and in fact put > into a logfile). I therefore propose the attached patch, which sends > log(9) to the message buffer always, and to the console only if no one > has yet opened the log. This makes sense to me. Since I'm new here, I'll wait for others to comment. Eric ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Early use of log() does not end up in kernel msg buffer
Using log(9) when no process is reading the log results in the message going only to the console (contrast with printf(9), which goes to the console and to the kernel message buffer in this case). I believe it is truer to the semantics of logging for messages to *always* go to the message buffer (where they can eventually be collected and in fact put into a logfile). I therefore propose the attached patch, which sends log(9) to the message buffer always, and to the console only if no one has yet opened the log. It may be more complete to log to the console only if the log level is greater than some (user defined) value, but this seems like that might be more than necessary for this case. Thoughts? Eric diff --git share/man/man9/printf.9 share/man/man9/printf.9 index 84ac822..505ea9b 100644 --- share/man/man9/printf.9 +++ share/man/man9/printf.9 @@ -67,7 +67,8 @@ The .Fn log function sends the message to the kernel logging facility, using the log level as indicated by -.Fa pri . +.Fa pri , +and to the console if no process is yet reading the log. .Pp Each of these related functions use the .Fa fmt diff --git sys/kern/subr_prf.c sys/kern/subr_prf.c index 7e6fd09..6509522 100644 --- sys/kern/subr_prf.c +++ sys/kern/subr_prf.c @@ -295,7 +295,7 @@ log(int level, const char *fmt, ...) va_list ap; va_start(ap, fmt); - (void)_vprintf(level, log_open ? TOLOG : TOCONS, fmt, ap); + (void)_vprintf(level, log_open ? TOLOG : TOCONS | TOLOG, fmt, ap); va_end(ap); msgbuftrigger = 1; ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"