[Prev][Next][Index][Thread]

Re: No utmp entry...



In article <31e63f75.0@hawkeye.inetw.net> write:
>For the longest time we experienced a frustrating, and 'seemingly'
>unknown bug with linux.  We have run several different kernels, new
>installs, old installs, the whole gamut, but whenever we added shadow
>support to one of our UNIX machines, we'd start seeing the message,
>"No utmp entry.  You must exec "login" from the lowest level "sh"" on
>serial (only) logins.  Sometimes removing ./utmp would cure it,
>sometimes killing the gettys on the serial lines would cure it,
>sometimes nothing would cure it.  I had heard complaints at times of
>people attempting to login upwards of 10-15 times before they'd get
>through.  
>The (apparent) answer to the problem was to look in the shadow src
>files we used since the problem never occured prior to installing
>shadow.  While ferreting around in our shadow src, I found the error
>message in utmp.c that we were experiencing.  Evidently the shadow
>login binary is _extremely_ picky about the format of utmp and if
>something is out of place, the error message is displayed, and the
>connection closed.  In the following section of code, I commented out
>the utmp check (picky) and recompiled shadow.
>
>
>./shadow/utmp.c
>        /* If there is one, just use it, otherwise create a new one.
>*/
>        if (ut) {
>                utent = *ut;
>        } else {
>-->                /* - if utmp is screwed up, can't log in to fix it$
>                if (picky) {
>                        puts(NO_UTENT);
>                        exit(1);
>                }*/                                               <--
>                line = ttyname(0);
>                if (!line) {
>                        puts(NO_TTY);
>                        exit(1);
>                }
>
>which has made the problem disappear.  I am not a programmer, and I am
>not too sure of the wisdom of doing this, or the real outcome on utmp
>but I do know the following:
>
>	- Our users can login now without that damn message.
>	- Finger still works.
>	- The systems we did this too stay up just as long as before this
>                    change.
>
>Hopefully this 'change' will help someone else avoid trying to fix
>this problem.  If anyone has any feedback or information about this,
>I'd appreciate hearing it.
>
>John
>

Is it your problem also ?

Oleg
====================
oleg@hpcms.co.il
====================