Xref: utzoo unix-pc.bugs:106 comp.sys.att:7842
Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!rutgers!texbell!attctc!kcdev!cpsolv!rhg
From: rhg@cpsolv.UUCP (Richard H. Gumpertz)
Newsgroups: unix-pc.bugs,comp.sys.att
Subject: Re: problems with UUCP and SETGETTY
Message-ID: <426@cpsolv.UUCP>
Date: 21 Oct 89 06:03:13 GMT
References: <417@cpsolv.UUCP> <988@icus.islp.ny.us>
Reply-To: rhg@cpsolv.uucp (Richard H. Gumpertz)
Organization: Computer Problem Solving, Leawood, Kansas
Lines: 25

In article <988@icus.islp.ny.us> lenny@icus.islp.ny.us (Lenny Tropiano) writes:
>Yes, those problems are pretty old.  I can't remember the specifics, although
>I believe they were fixed.  If they weren't fixed there were public domain
>version of setgetty (John Milton wrote) that did the same thing.

Anybody out there know anything about the "fixed" setgetty?  John Milton maybe?


>|>5) Any ideas that might lead me to eliminating the setgetty problem?  Any 
>|>   ideas what causes it?
>
>A malformed /etc/inittab file may hang setgetty.  Basically if there is no
>space in front of a [uu]getty line it *might* lock up uugetty.

My /etc/inittab looks fine: it has a ":" at the beginning of the line in
question.  Killing the looping setgetty and then running "setgetty 001 1"
manually works just fine.

I am still curious what is causing the original setgetty to sometimes loop,
usually when the system is unattended.  Anybody know?
-- 
==========================================================================
| Richard H. Gumpertz   rhg@cpsolv.UUCP -or- ...!uunet!amgraf!cpsolv!rhg |
| Computer Problem Solving, 8905 Mohawk Lane, Leawood, Kansas 66206-1749 |
==========================================================================