utmp problems in AT&T Sys V/386 3.2.2

Conor P. Cahill cpcahil at virtech.uucp
Sat Jan 26 05:22:41 AEST 1991


In article <1991Jan24.205726.11944 at informix.com> aland at infmx.informix.com (Colonel Panic) writes:
>Maybe this is in the FAQ, but I haven't seen one in so long. (Conor,
>you out there?)

Yes I am here.  No this isn't in the FAQ.  Yes I will be putting out a 
new FAQ next week.  Things have been real hectic at the office and at 
home for the past couple of months, but hopefully things will be settling
down now & I can get back to the real important stuff like reading 
news.

>This is probably something simple and stupid in setting up or using
>utmp, but I can't find it offhand.  If I try to run "login" from
>an existing login shell (sh or csh), I get the passwd prompt, then
>the message:
>No utmp entry.  You must exec "login" from the lowest level "sh".
>
>What does it take to fix this?

The problem is that login requires an entry in /etc/utmp when it
runs.  This is normally provided by getty when it executes the login.

When you are already logged in as a shell and you run login, the login
process id is not the process id of the entry in the utmp file and 
therefore won't let you do it.  However, if you instead run "exec login"
this will work because the login  process will take the place of your
shell process and therefore have the process id that corresponds to 
the id in the utmp file.

If you don't want to exec login, but just want to be another user while
being able to fall back to where you were, use su with a first argument of
a dash.  This will act like you logged in as that user.
For example:

	su - cpcahil

would "log" you in as cpcahil, with the exception that the utmp entry
would not be updated.  Note that you can do this even if you aren't 
root -- you will just need the password for  the account you are attempting
to su to.

-- 
Conor P. Cahill            (703)430-9247        Virtual Technologies, Inc.
uunet!virtech!cpcahil                           46030 Manekin Plaza, Suite 160
                                                Sterling, VA 22170 



More information about the Comp.unix.sysv386 mailing list