HP-UX newbie SOS

[David Silvasi]

I have an HP9000 running HP-UX 11 to play with and have run into trouble (as I presume most of you have!). I killed the wrong process by typing the wrong PID and it seems that I wiped out the mount of a volume. fstab, bdf, and a wide-open find listing are included in the attachment.

The session is hung once I get the NFS server not responding message but the 'still trying' messages keep coming until I disconnect.

How do I go about finding which volume(s) to re-mount if this is indeed the issue?

It has been suggested that rebooting would solve the problem but 1) I have no idea what has been going on with this machine in the 3-4 months since last boot; and 2) that is the wimpy way out that doesn't add to my learning experience!

Any suggestions are greatly appreciated!

[A. Clay Stephenson]

I'm guessing that you killed the NFS client daemons.
cd /sbin/init.d
./nfs.client stop
./nfs.client start
then execute mountall -r to mount all remote
filesystems
If you were a really bad boy you killed inetd
In which case only the console and directly
attached serial terminals can connect. If that is the case then from the /sbin/init.d directory
./inetd stop
./inetd start
If you do a ps -ef listing and attach that we may be able to see what process(es) are missisg.

[David Silvasi]

Thank you for your reply!

I get a nfs.client:not found message when executing nfs.client start or stop command. I did verify that the nfs.client is in the directory you stated.

Since I am connecting through a telnet session over a network I doubt that "I was a really bad boy" ;)

Here is a ps -ef listing....I see that some of the jobs run from my previous connection are still lingering! Let me know if you need anything else.

Thanks,
David

[Stefan Schulz]

Hello David,

also think you killed your nfs client. You should be able to restart it as root. Just as mentioned above.

As you got a "not found" message: did you type nfs.client start or ./nfs.client start? (note the "./"). This errormessage seems like the shell isn't able to locate the script as the root user has no "." set in the PATH.

Hope this helps. Stefan

[Shannon Petry]

I think your gonna have to bounce the server. If you look in the list of commands, you have lots of nicely hung commands, which I think if you did a ps -elf and check the state of all the bdf commands and find commands you will find them in the zombie state.

It is hard to say what you killed. To me also it looks like nfs client processes are not running. NOTE: no nfsd's and not automountd.

Either give the absolute path to the command /sbin/init.d/nfs.client stop then /sbin/init.d/nfs.client start or as some said cd to /sbin/init.d and give the relative path ./nfs.client stop then ./nfs.client start.

I would recommend you stop the process before starting, as you are not sure if you killed any of the rpc processes,

We all oops starting out. Hard to realize sometimes how much power and control root has esp if you come from windblows environments! As long as you learn from mistakes, then sh&% happens!

Regards,
Shannon

[Paula J Frazer-Campbell]

David

The quickest fix as it is a play server is reboot it and learn from a mistake ( as we all have done).

I remember killing pid 1 once (OOOPS) - (it is very interesting to watch a server slowly die).

;^)

Paula

[A. Clay Stephenson · Accepted solution]

David,
When I got in this morning I saw your ps listing. It appears that the portmap process is missing. This would cause a host of problems. I would suggest that you reboot at this point but if you are determined to try to
fix this then here are the steps.
FROM THE CONSOLE as root:
cd /sbin/init.d
./nfs.client stop
./nfs.server stop
./inetd stop
./nfs.core stop
# The portmap process must start before inetd
./nfs.core start
./inetd start
./nfs.server start
./nfs.client start

If this doesn't work then you will almost certainly have to reboot because there are so many interdependent processes.

./

[Vincent Stedema]

On HP-UX 11.00 the portmap process is called rpcbind, and it's up and running. My guess is that your problems have something to do with your pfs_mountd processes. That explains why those bdf's and "mount /cdrom" processes are hung.

Kill all the pfs_mount.rpc and pfsd processes and if that doesn't work....reboot.

Vincent

[David Silvasi]

Hello and thanks to all!

It looks like everything is ducky again. This is what I did:

FROM THE CONSOLE as root:

/sbin/init.d/nfs.client stop
/sbin/init.d/nfs.server stop
/sbin/init.d/inetd stop
/sbin/init.d/nfs.core stop
/sbin/init.d/nfs.core start
/sbin/init.d/inetd start
/sbin/init.d/nfs.server start
/sbin/init.d/nfs.client start

From here I ran the find command wide open and it parsed the entire file structure without errors or hanging. The bdf listing had a couple errors regarding the cdrom and I cleaned that up with a umount, mount of the cdrom. The processes that were in 'zombie' state were identified by the start date and killed.

There are 2 questions, though:
-Why was I able to do this from a telnet session instead of the console?
-What is the deal with the check mark? I had to use the full path to execute the necessary commands; changing to the /sbin/init.d directory and then executing gave 'not found' errors even though they were in that directory.

Thanks again to all who replied!

Best regards,
David

[Vincent Stedema]

1. console or pseudo-terminal, root has the same priviliges. Everything you run from the console can also be run from a pseude-terminal (unless you confine root access to the console)

2. ./ isn't a checkmark: it means "current working directory". Default, the PATH environment variable for root doesn't include "." (security hazard). That's why you either had to use "./nfs.client stop" or the full path, "/sbin/init.d/nfs.client stop". If you include /sbin/init.d in PATH for user root, you can just run "nfs.client stop". My advise would to just keep it like it is and NEVER put "." in your PATH...

Vincent

[Kevin Wright]

if you mean why were you able to kill and restart inetd from the console, that is because killing inetd does not terminate connections, it just keeps from allowing any more connections to establish..since you were already telneted to the server, it was possible to kill and restart inetd. Portmapper is started in the nfs.core script, which plays no part of the telnet service, nor do the nfs server and client scripts.