unexpected byte error

• Messages sorted by:[ date ][ thread ][ subject ][ author ]

Hi,

(I've put the mgetty list back on the CC:, as the mail contains stuff 
that I consider to be interesting for other readers as well).

On Wed, Nov 25, 1998 at 10:12:00PM +0100, Peter T. Breuer wrote:
> I mailed him that, and I didn't say that he SHOULD do that.  That is
> what he COULD do in order to redirect stderr from any executable
> launched from inittab.  

Well, it wouldn't change anything... :)

> That is what he asked how to do.  The fact that
> it's vgetty that he wanted to redirect means nothing in particular to
> me, and I don't know why he wants to do it, but that's how he can do it
> ("redirect stderr to devnnull") if he wants to.

Uh, yes, while that's true, it's pretty pointless for mgetty/vgetty.
Being a getty process, it's main *job* is to make sure stdin/stdout/
stderr points to /dev/modem, and not "somewhere that it happend to 
be connected to before".  So the redirection to wherever will survive only
a couple of milliseconds :)

Mgetty/vgetty won't write anything to stderr anyway, except in case of
wrong arguments on the command line (maybe not even then).

[..]
> > > /usr/local/sbin/vgetty $* 2>/tmp/errorlog
> > 
> > This will change exactly *nothing*, as vgetty will close its
> > stdin/stdout/stderr anyway, and reopen them to /dev/modem.
> 
> In that case stderr in inittab has nothing to do with it, 

Yes.

> and indeed, he
> should just read the docs to see how to get vgetty to spew into a file
> of his choosing, devnull maybe, or just not spew at all.  Why does it
> direct stderr to /dev/modem by default, if that is what you are saying
> (/dev/modem !  - I don't believe I'm seeing you writing this!)

Uh, I am not really writing "/dev/modem", I'm just too tired to start
shouting about not using this :) - it was his example, so I followed his
namings.

As for redirecting stderr to "/dev/whatever": mgetty/vgetty MUST redirect
stdin/stdout/stderr to the modem device, to make sure data login works.
For fax calls, it's doesn't matter (no output anyway, and when "new_fax"
is called, everything is redirected to /dev/console).  For voice calls
with forked children scripts, it *does* matter, because vgetty doesn't
(didn't yet?) bother to close stderr, or redirect it elsewhere.

Marc S.: maybe it would be a good idea to redirect children's stderr to
the vgetty log file?  Sort of what Apache does for CGI binaries?

gert
-- 
USENET is *not* the non-clickable part of WWW!
                                                           //www.muc.de/~gert/
Gert Doering - Munich, Germany                             gert@greenie.muc.de
fax: +49-89-35655025                        gert.doering@physik.tu-muenchen.de