🚀 go-pugleaf

In my experience, a syntax error in /etc/gettydefs can
cause "..respawning too fast". Try comparing the two
machines in this regard.

Svend

In article <3879DACF.7C440EE0@get2net.dk>, Svend Garnaes
<seg.dantaet@get2net.dk> writes
>In my experience, a syntax error in /etc/gettydefs can
>cause "..respawning too fast". Try comparing the two
>machines in this regard.
>
Sounds plausible but they are identical.
-- 
Martin Liddle, Tynemouth Computer Services, 27 Garforth Close, 
Cramlington, Northumberland, England, NE23 6EW.
Phone: 01670-712624.  Fax: 01670-717324.

In article <VcTd2FA1Mce4Ewrg@tcs02.demon.co.uk>, Martin Liddle
<martin@tcs02.demon.co.uk> writes
>I have read the Serial-HOWTO but haven't yet found a solution to my
>problem.  I have two essentially identical PCs running RedHat 6.0.  The
>installations are both recent.  Both PCs have two standard serial ports
>and a Specialix SI multi port intelligent serial adaptor.  The
>Specialix are using the current driver from the Specialix FTP site.  On
>one PC I can run a getty (for a Wyse terminal) on either the standard
>serial ports or the Specialix.  On the other PC attempting to run a
>getty on either the standard serial port or the Specialix fails with the
>"..respawning too fast.   Disabled for 5 minutes" message.  I have tried
>on ttyS1 with both the standard RedHat kernel and a kernel that I have
>built. However I can successfully do a "cp file /dev/ttyS1" which leads
>me to suspect that the hardware isn't completely dead.  I also know that
>the hardware was working correctly very recently under an old version of
>Sunsoft Interactive Unix.  (Unfortunately I can't easily go back and
>check again as the Linux install seems to have clobbered Interactive in
>some way.)
>
I have continued to struggle with this problem today without much
progress.  However I have noticed one thing.  On the machine where getty
runs there are entries for interrupts 3 and 4 in /proc/interrupts
however on the machine where getty respawns these entries are absent.  I
don't know whether this is acsue or effect.  I can use setserial to
specify interrupts (and setserial reports the changed interrupt value)
but that still doesn't result in entries in /proc/interrupts.  I am
again running out of ideas.  Help! 
-- 
Martin Liddle, Tynemouth Computer Services, 27 Garforth Close, 
Cramlington, Northumberland, England, NE23 6EW.
Phone: 01670-712624.  Fax: 01670-717324.

Compare /var/log/dmesg on the two boxen to see
if one has a problem detecting the ports.
If so, check that the multi port adaptor has
the same config on both boxen.
Also, have you checked the nodes in /dev ?

Svend

In article <387A3E68.AA653ACE@get2net.dk>, Svend Garnaes
<seg.dantaet@get2net.dk> writes
>Compare /var/log/dmesg on the two boxen to see
>if one has a problem detecting the ports.
>If so, check that the multi port adaptor has
>the same config on both boxen.
>Also, have you checked the nodes in /dev ?
>
Thanks for your help.  The serial port detection is the same on both
boxes.  The nodes in /dev are the same.  

I decided that as I couldn't find a software configuration problem then
the problem must be in hardware.  I've just put in a spare motherboard
(the standard serial ports are on the motherboard) of the same type.
The problem remains.  Getting desperate.
-- 
Martin Liddle, Tynemouth Computer Services, 27 Garforth Close, 
Cramlington, Northumberland, England, NE23 6EW.
Phone: 01670-712624.  Fax: 01670-717324.

Martin Liddle wrote:
> 
<snip>
> On the other PC attempting to run a
> getty on either the standard serial port or the Specialix fails with the
> "..respawning too fast.   Disabled for 5 minutes" message.
<snip>

I have seen a similar message on SCO OpenServer 5.0.x systems. I had a look
at the SCO Technical Articles (http://www.sco.com/ta) using the keywords
"respawn" and "getty". Here are the top 2 suggestions for the cause of the
error. (Their relevance to Linux may be questionable: see what you think.)

1. /etc/inittab contains duplicate entries. getty cannot successfully start
when another getty is already running on the line. To fix: edit /etc/inittab
by hand and remove the offending entry. Check /etc/conf/cf.d/init.base and
the files in /etc/conf/init.d to make sure they do not also contain the
duplicate entry. 
[I am not overly familiar with Linux so the /etc/conf/cf.d/init.base and
/etc/conf/init.d pathnames may not apply...]

2. /etc/getty has somehow become corrupted. To quickly check whether getty
is working, run the command: 
   getty -c /etc/gettydefs
If this produces a large amount of output showing the contents of
/etc/gettydefs then getty is probably OK.  It is not possible to check
getty's checksum because the file is serialized.
<obviously SCO specific getty recovery stuff removed>

-- 
Richard Howlett

mailto:richard@howie.org.uk

In article <387A6C97.FE2DC8EF@get2net.dk>, Svend Garnaes
<seg.dantaet@get2net.dk> writes
>Could still be a syntax error.
>Check that /etc/inittab is the same on the two boxen
>
OK everybody, repeat after me "Martin is an idiot, Martin is an
idiot....".  You are quite right.  I'd only looked at it a million times
without spotting that on the computer that was respawing I'd specified
the port as /dev/ttyS1 where the /dev/ is of course wrong.

One thing I learnt along the way that may help someone is that you only
see an entry in /proc/interrupts when a process is actually using the
associated device.  So the lack of an entry was simply a symptom of
getty not running.

Thank you for your help.
-- 
Martin Liddle, Tynemouth Computer Services, 27 Garforth Close, 
Cramlington, Northumberland, England, NE23 6EW.
Phone: 01670-712624.  Fax: 01670-717324.

In article <387A6C68.6D26EC59@NOSPAM-howie.org.uk>, Richard Howlett
<richard@NOSPAM-howie.org.uk> writes
>I have seen a similar message on SCO OpenServer 5.0.x systems. I had a look
>at the SCO Technical Articles (http://www.sco.com/ta) using the keywords
>"respawn" and "getty". Here are the top 2 suggestions for the cause of the
>error. 

I have now sorted the problem.  See my explanation elsewhere in this
thread.  Thank you for your help.

-- 
Martin Liddle, Tynemouth Computer Services, 27 Garforth Close, 
Cramlington, Northumberland, England, NE23 6EW.
Phone: 01670-712624.  Fax: 01670-717324.

Martin Liddle wrote:
> 
> In article <387A3E68.AA653ACE@get2net.dk>, Svend Garnaes
> <seg.dantaet@get2net.dk> writes
> >Compare /var/log/dmesg on the two boxen to see
> >if one has a problem detecting the ports.
> >If so, check that the multi port adaptor has
> >the same config on both boxen.
> >Also, have you checked the nodes in /dev ?
> >
> Thanks for your help.  The serial port detection is the same on both
> boxes.  The nodes in /dev are the same.
> 
> I decided that as I couldn't find a software configuration problem then
> the problem must be in hardware.  I've just put in a spare motherboard
> (the standard serial ports are on the motherboard) of the same type.
> The problem remains.  Getting desperate.
> --

Could still be a syntax error.
Check that /etc/inittab is the same on the two boxen

Svend