Login Incorrect !!

[Amol Lele]

Server HP-UX 11i.
We are trying to login to our production system. However as soon as we try to reach the telnet screen and type the login in at login prompt, it displays error Login Incorrect.
**** Screen Shot Start *****
HP-UX geamqtz2 B.11.11 U 9000/800 (tu)

login: mfg
Login incorrect
login: LELEA
Login incorrect
login:
**** Screen Shot End *****
Addtional Information:
1) Tried to chek /etc/passwd file. File is intact.
2) Existing users are able to continue working fine.
3) No switch user is working.
4) FTP from any external device is not working as login fails.

Has any one experienced such problem ? Any knowledge is helpful.

Thanks, Amol Lele.

[Rick Garland]

Check kernel parameters for number of ptys, number of telnet session device files, etc.

[Amol Lele]

Thnx Rick. We tried checking the Kernel Parameter but on access to SAM its giving:
*** Screen Shot Starts ****
/usr/lib/dld.sl: Call to mmap() failed - TEXT //usr/obam/lib/libobam.1
/usr/lib/dld.sl: Not enough space
/usr/sbin/sam[220]: 6571 Abort(coredump)
*** Screen Shot Ends ****
We tried to check bdf for /usr & its at some 90 %. Do you think thats causing this problem ?

[Victor BERRIDGE]

Hi
What about /var ? is it full?
Do you have glance?


All the best
Victor

[Amol Lele]

Thnx Victor. /var is as well 75% so even that in comfort zone. Glance appears health as well.
*** Screeshot extract from Glance ****
Current Avg High
---------------------------------
CPU Util 22% 20% 29%
Disk Util 41% 8% 41%
Mem Util 75% 75% 75%
Swap Util 47% 47% 47%
---------------------------------
*** Screeshot from Glance Ends ****

[Victor BERRIDGE]

So from glance or gpm& (in X mode)
Look for system info->system table graph or report: Is Pseudo terminal table full?

other possibilities /etc/passwd corrupted my non printable character...

All the best
Victor

[Victor Fridyev]

Hi,

The computer does not have free memory for allocation.
usr/lib/dld.sl: Call to mmap() failed - TEXT //usr/obam/lib/libobam.1
/usr/lib/dld.sl: Not enough space
You can see this by swapinfo or another similar program.
You can either kill a process with memory leak or reboot the machine.
In order to see suspected processes run
ps -el |sort -nr -k 10,11|more

HTH

[Victor BERRIDGE]

Hi again
I missed that one about memory, your swap seem to used quite alot... I would suggest while in gpm to lookt out at all the system tables... (shared memory table more specificaly...)


All the best
Victor

[Amol Lele]

Thanks to everyone, who is pooling in their thoughts. For server glance on system table report appears quite good. Only thing I felt abnormal is "Buffer Headers" is:
System Table Available Used Utilization High(%)
--------------------------------------------------------------------------------
Buffer Headers (nbuf) na 127398 na na
Proc Table (nproc) 6420 763 12 12
File Table (nfile) 154870 12198 8 8
Shared Mem Table (shmmni) 500 153 31 31
Message Table (msgmni) 500 2 0 0
Semaphore Table (semmni) 800 53 7 7
File Locks (nflocks) 256 30 12 12
Pseudo Terminals (npty) 500 1 0 0
Buffer Headers (nbuf) na 127398 na na

[Victor BERRIDGE]

Hi,
There are 2 dinamic kernel params you can try to tune:
maxuprc but I wonder if its not maxtsiz giving trouble
Try to tune with kmtune maxtsiz to a greater value (to see its acutal value try sysdef or look at /stand/system)


Good luck and
all the best
Victor

[Rick Garland]

With multiple posts talking about kernel tuning, you may want to reboot the system now to allow users to get back to work ASAP. Tune the kernel later today/tonight when activity is not as heavy.

Only issue here is that you cannot test what you have tuned until the next heavy load.

[john korterman]

Hi,
try checking doc. id KBRC00014415 in the technical knowledge base.
If that is not the answer to your problem, it could be interesting to know the size of physical memory and swap space of your system.

regards,
John K.

[Bill Hassell]

Just a note: maxuprc simply limits the number of processes (not sessions) run by any user except root. If some the mfg user is running 60 processes, then you'll hit the process table limit but you never get a memory error (ie, not enough memory or space). maxtsiz never needs changing in a typical system. This is the maximum size for instructions and is normally 8megs or 67megs. 8megs means millions of instructions (not data) so for a process to hit the maxtsiz, the executable would have to be more than 8 megs in size and it would never start.

It would appear that someone has changed permissions on important directories and/or files. If you have any root logins still working, use it to look at root's shell history. Look for chmod, especially chmod -R. I hope you don't have any duplicate root users (use the logins -d command) but if so, check their shell histories too. Make sure these directories are 755 permissions:

/ /etc /dev /usr /var /opt /sbin

[Amol Lele]

Thanks Everyone, Thanks a lot for all your help. This problem was related to some extra memory usage on by one of our application databases. As soon as restarted the databases with fine-tuned parameters on database buffer size, it started working back up. Regardless of this we have re-started the server and things are back to normal. Thanks Once Again.