NFS and Log

[Wood_2]

Hello,

How can i put nfsd in debug mode.
I would like to find a log because I can't connect to my server.

Thank you for your help

Nicolas

[Muthukumar_5]

/var/adm/syslog/syslog.conf will contain nfsd logging informations there. If you changed the default configuration file on /etc/syslog.conf then refer that file.

Are you trying to connect NFS server then, you can use nfsstat command to know the problem there.

mount -p what is saying?

Try to check connectivity of nfs server with ping / nslookup service there.

REgards
Muthu

[Dave Olker]

Hello Nicolas,

There is no debug logging facility for nfsds at this time. We will be introducing a debug logging facility for nfsd in the next OS release.

When you say you can't connect to the server, are you saying it fails when you try to mount the filesystem, or does the filesystem mount correctly but you get an error when you attempt to access the mounted filesystem? Either way, please tell me the exact commands you're using and the exact error messages you're receiving.

Regards,

Dave

[Steven E. Protter]

inetd -l to turn on enhanced logging.

tail -f /var/adm/syslog/syslog.log

Then try a connect. If the session is connecting at all diagnosic data may be found.

If nothing shows up in syslog, tcpdump or ethereal might be used to sniff the packets and try and figure out whats going on with the NFS requests.

ps -ef | grep nfsd to see if there are any running daemons.

SEP

[Dave Olker]

Hi Stephen,

NFS no longer uses inetd for any reason. A long time ago rpc.mountd was managed by inetd, but HP stopped configuring rpc.mountd via inetd several years ago. We no longer support customers managing rpc.mountd via inetd. NFS traffic itself has never gone through inetd.

Nicolas: if the NFS mount is failing at MOUNT time (i.e. the initial mount of the filesystem fails) then the best logging to enable would be debug rpc.mountd logging. To do this you would send the running rpc.mountd daemon a SIGUSR2 signal:

# ps -ef | grep rpc.mountd
# kill -17

This will enable full debug logging to the /var/adm/mountd.log file. Reproduce the mount failure again and then send the running rpc.mountd another SIGUSR2 signal to toggle debug logging off:

# kill -17

The /var/adm/mountd.log file should show why the mount is failing, or point to the subsystem that is causing the mount to fail.

If you collect this log file data, assuming the problem occurs at MOUNT time, and you need help interpretting the log file contents let me know and I can help.

If the problem occurs after the filesystem is successfully mounted, then Stephen had the right idea to collect a network trace using whatever collector you prefer - tcpdump, nettl, ethereal, etc. If you need help analyzing the network trace, again assuming the problem occurs AFTER the filesystem is mounted, I can help there too.

Regards,

Dave

[jamesps]

Dave,

11 points from me and a virtual 12-pack of anything you want :)

I have personally got out from a weird NFS issue and used the solution you suggested in order to enable trace on for rpc.mountd.

Just wanted to say thanks to you and thanks HP for having this awsome forum!

James.

[Dave Olker]

James,

Glad I could help. :)

Just as a reminder, the "kill -17" trick works for other daemons besides rpc.mountd. It works on rpc.statd, rpc.lockd and automountd as well - just in case you run into strange problems with those daemons.

Dave

[jamesps]

Dave,

Thanks again for sharing that to us. I wonder if is there a reason why HP chose not to enable verbose logging for nfsd like there is in linux, simply via syslog. I am using B.11.11.

James.

[Dave Olker]

Hi James,

I'm not familiar with nfsd logging in Linux, but my guess is HP chose not to do any debug nfsd logging via syslog because of performance reasons.

My understanding is that syslog is user-space stuff and the nfsd code is all kernel-based. I believe the nfsd would have to context switch to user-space in order to do the log write and then back to kernel space to complete the actual NFS request and this could get very expensive. Also, the system calls nfsd would have to make to format a "nice" syslog message (possibly gethostbyname/addr, etc.) could also get very expensive. I could be wrong about this, but that's my guess.

The logging we're implementing in 11iv3 is kernel based. The nfsd writes to a circular buffer in kernel memory and a separate daemon extracts the data from this buffer and formats the "nice" log messages. This mechanism should allow nfsd to log its activity with a very minimal performance hit.

Again, just my guess.

Regards,

Dave