On Wed, 6 Dec 2000, Cokey de Percin wrote:
> Matthew Melvin wrote:
>
> Well, I'm using a serial terminal and I don't have a problem getting
> in Single, but my setup looks like this:
>
> S0:12345:respawn:/sbin/uugetty -d /etc/conf.uugetty.ttyS0 ttyS0 DT9600 vt100
> ^
> Note the '1'... I believe you need this set connection spawned in run
> level 1.
>
Hmmm... I tried this but I still get the same thing.. a "bash#" prompt that
looks fun that does nothing. But this is kind of what I would expect. The
last thing run level 1 does is switch to runlevel S so my getty goes away
anyway.
Initializing random number generator [ OK ]
Telling INIT to go to single user mode.
INIT: Going single user
INIT: Sending processes the TERM signal
getty[161]: exiting on TERM signal
INIT: Sending processes the KILL signal
bash#
This is if I go switch to runlevel 1 from multiuser or start up in runlevel
1. If i go straight to runlevel S it behaves as before. Again what I'd
expect becuase the 1 entry never comes into play.
Anyway - all of that aside I don't have any trouble running getty in single
user mode (using the inittab entries from my previous email) I just don't
see that as being desirable. If the system's sufficently toast that I need
to be in S then I don't want to have rely on login working and root's
account being functional.
I tried it boths ways but are getty and uugetty functionally different in
anyway? What's in your /etc/conf.uugetty.ttyS0 - could that be relevent?
Stopping getty from dieing on TERM maybe or perhaps starting a shell itself
instead of prompting for a username and then starting login?
M.
--
WebCentral Pty Ltd Australia's #1 Internet Web Hosting Company
Level 1, 96 Lytton Road. Network Operations - Systems Engineer
PO Box 4169, East Brisbane. phone: +61 7 3249 2583
Queensland, Australia. pgp key id: 0x900E515F
_______________________________________________
Redhat-list mailing list
[EMAIL PROTECTED]
https://listman.redhat.com/mailman/listinfo/redhat-list
