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 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 6 April 2015 at 14:11, Poul-Henning Kamp p...@phk.freebsd.dk 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 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 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
