[9fans] pprint and exportfs (and others)

[9fans] pprint and exportfs (and others)

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 1083 bytes --]

In a few cases, the kernel will use pprint to put a diagnostic on the
standard error (file descriptor 2).
One of those is a warning that the process has used more than 100 file
descriptors.
That message is possibly obsolete and could be removed, but there are
others, such as
notifying an uncaught trap that are probably helpful to make visible.
In any case, as things stand, a busy exportfs might have many file
descriptors open,
provoking the diagnostic. Unfortunately, aux/listen and aux/listen1 connect
file
descriptor 2 to the incoming network connection. If the connection's
protocol is
not a simple, unstructured, textual one, diagnostics on the standard error
will cause confusion, in particular to devmnt.c if 9p is used.

/rc/bin/service files that start applications that run special protocols
might want to
redirect file descriptor 2; alternatively, perhaps aux/listen shouldn't
redirect fd 2 by
default: the few commands that do connect the remote user to shells, or
equivalent, including
telnetd and sshd could dup 1 to 2 when that was sensible.

[-- Attachment #2: Type: text/html, Size: 1310 bytes --]

Re: [9fans] pprint and exportfs (and others)

[lucio]

> In a few cases, the kernel will use pprint to put a diagnostic on the
> standard error (file descriptor 2).

What's wrong with kprint (or logging) for this?

++L

Re: [9fans] pprint and exportfs (and others)

[erik quanstrom]

On Wed Apr 17 13:38:02 EDT 2013, lucio@proxima.alt.za wrote:
> > In a few cases, the kernel will use pprint to put a diagnostic on the
> > standard error (file descriptor 2).
>
> What's wrong with kprint (or logging) for this?

that's what pprint() does.  it prints info about
the current (offending) process, and then the message.
for other kernel logging, one simply uses print.

there is no kprint in plan 9.  neither can one
syslog from the kernel.

- erik

Re: [9fans] pprint and exportfs (and others)

[lucio]

> there is no kprint in plan 9.  neither can one
> syslog from the kernel.

I was going to be clearer, then got lazy:

-lr--r----- c  0 lucio lucio       0 Mar 21 20:44 /dev/kprint

that's the console, I've never investigated how the kernel writes to
it, but it sounds like the right place for diagnostics that should not
get mixed up with the user's stderr.

++L

Re: [9fans] pprint and exportfs (and others)

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 681 bytes --]

The user is intended to see these messages: that's the point of pprint. The
messages refer to a program the user is running. It produces diagnostics
from the kernel to the user, and thus correctly uses standard error.
On 17 Apr 2013 18:54, <lucio@proxima.alt.za> wrote:

> > there is no kprint in plan 9.  neither can one
> > syslog from the kernel.
>
> I was going to be clearer, then got lazy:
>
> -lr--r----- c  0 lucio lucio       0 Mar 21 20:44 /dev/kprint
>
> that's the console, I've never investigated how the kernel writes to
> it, but it sounds like the right place for diagnostics that should not
> get mixed up with the user's stderr.
>
> ++L
>
>
>

[-- Attachment #2: Type: text/html, Size: 974 bytes --]

Re: [9fans] pprint and exportfs (and others)

[cinap_lenrek]

its not just pprint(). stuff like sysfatal() will also write to
fd 2... or abort()... having the kernel write to your std error
has some practical value imho.

having errors from listeneres appear on the cpu server console
(or a logfile?) instead in the middle of some unknown protocol
stream makes sense as a default for aux/listen.

--
cinap

Re: [9fans] pprint and exportfs (and others)

[erik quanstrom]

> having errors from listeneres appear on the cpu server console
> (or a logfile?) instead in the middle of some unknown protocol
> stream makes sense as a default for aux/listen.

a logfile would be better.  i have a system that gets
attacked occasionally, and spamming the console
would only make matters worse.  however, having
the service/whatever script redirect to a log file
might be an improvement.  listen perhaps could
open /dev/null on stderr and leave it up to the script.

- erik

Re: [9fans] pprint and exportfs (and others)

[cinap_lenrek]

it looks like telnetd doesnt even need any changes. it explicitely
opens /dev/cons (which got bound over with the network connection
by listen) and dups it to fd 2 for the subshell. tho i havnt tried
it yet.

--
cinap