unexpected byte error

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

Hello,

Gert Doering wrote:
> 
> 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.

Thank you for your mail. Pleas don't misunderstand me. I didn't complain
about your hints or anything. I'm very happy to got responce that
spontaneously. I just tried it, it didn't work. There is no problem for
me. I know that I'm responsible for what I'm doing, it doesn't change
much for me, if you write COULD or SHOULD.

> 
> 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 reounexpected byte errorpen 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!)

I read the docs, but I found this thread "unexpected byte error" and
didn't know what scripts they are talking about. Now it's clear, Thank
you Gerd, and I can spy for the problem.

> 
> 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.
> 

Here as well, I read your docs and decided to use "/dev/modem"
nevertheless. I hadn't any problems with that until now, becaus I read
the docs.


> 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.

Thank you for this explication.

> > > > I tried it but now I can't use my pppd anymore to dial into the internet.

> > Sounds like "read the docs" - don't send weird e-mails not relevant here,
> > send a PPP and vgetty log of your tries.  Most likely you got the lock
> > file wrong (no pppd lock, or wrong device name).

I didn't send weird e-mails to anybody. May be for you it's evidently,
that they are not relevant. Sometimes there are interactions between
programs using the same modem. So I just wrote what I experienced. Thank
you anyhow, to offer to have a look at the log. By the way, it wasn't
the lock file, I read about it allready in the docs.

Stephan

-- 
----------------------------------------------------------------------
Stephan Kahnt
TU Berlin	Tel : ++49 30 39006-241
REMOVE NOSPAM	mail: stephan.kahnt@ipk.fhgNOSPAM.de
----------------------------------------------------------------------