mgetty spawning too fast?

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

"GD" == Gert Doering <gert@greenie.muc.de> writes:

GD> Hi,
GD> mshack@mcs.com wrote:
>> [...]
>> d1 respawning too quickly, disabling for 5 minutes ...

GD> Sounds like a fatal error. Either the path to mgetty is wrong, or a shared
GD> library (ELF magic...?) is missing, or it's still a.out format, or or or.

Well, if it's still in a.out format it should run fine--*unless* you
didn't install any a.out compatability libraries when you did you
initial Red Hat installation.  If that's the case, you should recompile
mgetty so that it's in ELF format.  I think Gert can point you to the
source code.  :)~

If the shared lib's that mgetty needs (assuming an ELF mgetty binary...)
weren't there (referencing the above stab in the dark by Gert), you
wouldn't even get to the point that mgetty fails since your system
probably would not be booting successfully; all that mgetty should need
is libc, and since many binaries in the boot sequence need that you'd
notice any problems with it pretty quickly...

I'll have to look at the code to various versions of init (which version
does Red Hat run?) and see if an inittab entry with a bad path/filename
will cause a respawn in any of them, or if it will just immediately be
squashed as invalid.  Looking at the code to one version that I have
on-hand here (from NetKit-B), if the exec of the getty fails (e.g. for a
bad path) it appears to not respawn--it will just complain the first
time and give up.  (Now I'm curious about something...)

>> Thus, I get one call in and the game is over.  Mgetty is dead and the
>> modem will never answer again.

GD> Could be the modem cable, or the modem setup. Is the user shell terminating
GD> itself after logout? If not, init won't start a new (m)getty process.

We've had problems with Zoom modems misbehaving here.  They've sometimes
needed init strings that look like monkey puke in order to recover from
such "odd" events as the remote end hanging up.  But then, Gert knows a
hell of a lot more about this than I do...

GD> Make sure that the modem sets the DCD line properly (AT&C1) and that the
GD> CLOCAL flag is not set on the serial line (stty -clocal).

What about "&D2" as well?  (Damn...now I can't even remember what that
does!?!)

>> Third, is there any way, at runtime, to tell mgetty where the 
>> mgetty.config file is located?  

GD> No, because this would be a security hole (IMHO).

Unless the user doing it has a *real* uid of 0.  (It should then be OK.)

Sendmail does this sort of trick of course, giving up any privileges
(gained by its setuid bit) if you specify an alternate configuration
file at runtime.  But if you're already root then it's kosher...

--Up.

-- 
Jeff Uphoff - systems/network admin.  |  juphoff@nrao.edu
National Radio Astronomy Observatory  |  jeff.uphoff@linux.org
Charlottesville, VA, USA              |  http://www.cv.nrao.edu/~juphoff/