Subject: Re: bin/1715 (login(1) should be statically linked)
To: None <greywolf@starwolf.com>
From: Gordon W. Ross <gwr@mc.com>
List: current-users
Date: 05/15/1996 09:51:33
> Date: Tue, 14 May 96 15:47:12 PDT
> From: Open Carefully -- Contents Under Pressure <greywolf@defender.VAS.viewlogic.com>

> I'm just kind of cruising through old PRs which look like I can help, so
> I might be asking some interesting questions from time to time.
> 
> Like now.
> 
> 1.  Curiously, why did login move from /bin (4.(1 <= x <= 3) to
>     /usr/bin (4.4)?
> 
> 2.  Is there a reason login is not compiled statically?
> 
> 3.  ...or is this really a non-problem which should be closed and forgotten
>     about?
> 
> My first thought was that if your shared libs are losing on login,
> there's a good chance they're losing on something else as well and
> theoretically your machine should never make it to multi-user mode, but
> that only occurs if the shared libs disappear BEFORE you've gone
> multi-user -- if you lose your shared libs DURING multi- user mode,
> then, yes, you have a problem in that there is now no way to log in to
> attempt to fix things, even at the console.

Yes.  I get this with a (VM? pmap?) bug I've been trying to kill.
The machine makes it to multi-user, and then getty and/or login
just dumps core, leading init to say "spawning to rapidly..."
I have to use ddb to send signal 15 to init to gracefully drop
down to single-user mode.

It might be nice if getty and login were static, so at least root
could login when the shared libraries are not working...

Gordon