Cannot login: Please wait...checking for disk quotas

[Kevin R. Bulgrien]

HPUX 10.20 is running on:

$ model
9000/777/C110

# uname -a
HP-UX hostname B.10.20 A 9000/777 2010505180 two-user license

I cannot login to this system. I do not know HP-UX / CDE to speak of - this is an inherited system.

Console (CDE user session) is locked up at "Logout Confirmation" dialog with the "Continue Logout" button pressed. Scroll/Num Lock lamps are stuck off, but Caps Lock is not frozen. I have tried console keys normally useful with XFree86/XOrg to try to restart the X server or to shutdown/reboot, but these do not appear to work with CDE. The last thing that was done was to have the user unlock the console. He typed logout at a terminal session that was already open. Nothing happened, so then I right-clicked on the desktop select Logout that way. The "Continue Logout" button was pressed, and now we are here. I cannot say for sure the system was not already messed up before that as no one has actively used the system for a number of days, but cron e-mails were sent to me this morning, and the system is still pingable.

How may I regain access to the console?

Serial 1 configured for a mouse (9600 8N1 on terminal shows %Spaceware messages periodically.)

Serial 2 appears to not be configured.

Telnet to LAN address gives:

login: root
Password:
Please wait...checking for disk quotas

At this point, the telnet session is locked up even after waiting a half hour or more. The heartbeat indicator is blinking. Other indicators blink infrequently.

Is it possible this is a file system space issue - like /var being full? Surely root would be able to login to at least shutdown and or correct the problem.

What is an unlucky system admin to do in this situation? Pull the plug? Is there a way to be sure the disks are synced first?

Are there techniques to get in and find out what to do to resurrect the system. Some other UNIX systems I have used in the past would let a root user in even if non-permissioned users were locked out.

[OldSchool · Accepted solution]

Last time I ran across this, there were NFS hard mounts, and the link to the other server was down. Don't know if this applies in your case. It *eventually* timed-out.

[Kevin R. Bulgrien]

How did you know there is an NFS mount to another system. Wink. The host for that share is a SparcStation is powered down. All of this came about because a new UPS is being installed for both systems. I needed to try to shutdown the HPUX system to transfer power to the new UPS. The Sparcstation was shutdown first. Crossing fingers and turning all the power switches on now...

BINGO!

It's aaaallliiiiiiiiiiiiiiiiiive!

Oh my! Was there a patch that should have been installed to prevent this awful, awful behavior?

[Bill Hassell]

Welcome to the world of NFS. Unlike PCs which do not treat network filesystems the same way, all NFS disks in /etc/fstab must exist in order to bootup. The awful behavior is how it is. 10.20 went out of support several years ago so there are no patches. If I were you, I would remove the NFS entries from /eetc/fstab and manually mount the remote filesystems only when you know the server is working. NFS servers can never be taken down because they take all their clients with them.

The alternative is to use automounter but unless you are up to date on patches, the automounter may have some stability problems too.

[Kevin R. Bulgrien]

An NFS server was down. When the NFS server came back online, the problems disappeared. The first reply was the response I needed.