I'm fighting with a core dump / nfs issue and I'm hoping someone on LinuxQuestions might able to help.

I'm running Red Hat Enterprise Linux 5 (kernel 2.6.18-128), and am networked on a tiny, private network to a server that's running Solaris 10. I want core dumps that are generated by the Red Hat box to be written to an nfs-mounted directory on the Solaris box. I've successfully redirected core dumps locally on the RH box by setting /proc/sys/kernel/core_pattern to my desired directory/filename, but when I send them to the nfs-mounted directory on the Solaris box it will not write them.
Reroute process I used:
Local (works fine):
echo "/tmp/corefiles/core_%e_%t" > /proc/sys/kernel/core_pattern

remote, assume /var/remote is nfs mounted (fails to write file):
echo "/var/remote/path/core_%e_%t" > /proc/sys/kernel/core_pattern

I've also set "ulimit -c unlimited" to rule out any size issues.

I am able to write files to the mounted partition, both as root, and as a user, both before and after a core dump occurs (in fact I manually copied a local core file to the remote partition right after a core dump). To allow root to write to the mounted directory, on the Solaris box I have modified /etc/dfs/dfstab to allow root access on the private network, to prevent "root squash" as follows:
share -F nfs -o sec=sys,rw,root=@<first 3 bytes of my local IP> -d "Remote Log Directory" <path to mounted directory>

I've verified that root can write there by writing files onto that box while logged on as root on the RH box. When a seg fault occurs with my nfs re-route in place I only see "segmentation fault" but no (core dumped), and no error message.

Any idea what I'm missing? Thanks for any suggestions you might have!

- Sean

Hmmm. Can't see any reason that wouldn't work.

What user is the app which is dumping core running as?

Dave

Thanks for the reply, Dave. The app is initiated as root (in order to create some posix realtime threads), then changes its own user id to a particular user name (call it userx), which it remains at unless it needs to create another thread or a driver (in which case it temporarily becomes root and then returns to userx). When a crash occurs we have a crash handler that then changes the uid back to root, but I've tried taking that out, so it crashes as userx, with the only difference being that a local core file ownership is set to userx rather than root. But in either case, it won't write to the nfs mount.

However, all this is seems moot because I tried simply running an xterm window and causing it to 'crash' with a seg fault, and the same problem occurs. So it's not really app-dependent.

-Sean

Some findings:

Segfault'ing a Linux process on a local mount results in a normal core file.
Segfault'ing a Linux process on a Linux NFS mount results in a normal core file.
Segfault'ing a Linux process on a Solaris NFS mount results in an empty core file. Which is a bit odd.

I'd say this is a Linux Vs Solaris NFS thing rather than anything you've got set up wrong.

You might (just maybe) get some joy by mounting the filesystem as NFS2, rather than NFS3/4. I believe this is switched off by default on late Solaris builds. I'm also not entirely sure what versions of NFS Linux actually supports.

Dave

Edit:
I was going to suggest something like fuse-sshfs, but having tried it, no core dumps there either.

Dave, Thanks for testing this on your system -- I really appreciate your help! I'll look into NFS2. I also thought about routing the file to a pipe, but I think the max pipe buffer size could cause me trouble.

Sean

A pipe to a 'cat -' script might well work.
Maybe even a fifo called 'core' on the local FS, with a 'cat core > /nfs/mount/core' waiting (probably not, but you never know). I'd take a look myself, but I'm away from the Solarium at the moment.

Dave