nfs read errors when mounting fs on nfs server

F

FlyDrag

I discovered a problem with my home FreeBSD server. I'm using NFS to share filesystems from my server to another hosts. Any time I mount something using NULLFS on this server (something which is never related to any NFS export) - I'm getting errors on the NFS client side: 'Permission denied'. I discovered (in mountd debug) that every time I mount something by NULLFS - mountd re-reads it's configuration file (like -HUP signal). This causes great problems any time I'm running tinderbox - it mounts/unmounts nullfs frequently, and every nullfs mount causes errors on NFS client side. This is not tinderbox-related, because restarting ezjail or directly mount nullfs "by hand" has the same effect.

I have checked the mountd behavior while mounting ufs filesystem (nanobsd /cfg) - the behavior is exactly the same - it re-reads all config files and I have 'Permission denied' error on client.

In the case it make sense - all my NFS exports are on ZFS.

How can I fix this? After reading into mountd manual (and briefly looking into it's code) I have no idea:( This is extremelly annoying because I have errors on video playback for files from this server while running tinderbox.
 
I'm using ZFS, NFS and nullfs and I've never had any issues.

What version of FreeBSD are you running on what architecture?
 
Code: 
FreeBSD tarzan.private.flydrag.ru 8.2-STABLE FreeBSD 8.2-STABLE #0: Wed Mar 30 02:02:55 MSD 2011     
[email]root@tarzan.private.flydrag.ru[/email]:/mnt/system/obj/tarzan/mnt/system/src/8-STABLE/src/sys/GENERIC_FWD  amd64
 
I made some additional checking. This issue seems to be external to mountd. After checking it's sources deeply I discovered that it re-reads config file ONLY when it receives HUP signal. So I made a little patch to named, disabling get_exportlist after SIGHUP:
Code: 
> diff -u /mnt/system/src/8-STABLE/20110928/usr.sbin/mountd/mountd.c \
    /mnt/system/src/8-STABLE/mountd-debug/usr.sbin/mountd/mountd.c
--- /mnt/system/src/8-STABLE/20110928/usr.sbin/mountd/mountd.c  2011-09-28 13:48:34.028599000 +0400
+++ /mnt/system/src/8-STABLE/mountd-debug/usr.sbin/mountd/mountd.c      2011-12-05 17:08:54.795320018 +0300
@@ -561,7 +561,8 @@
        /* Expand svc_run() here so that we can call get_exportlist(). */
        for (;;) {
                if (got_sighup) {
-                       get_exportlist();
+//                      get_exportlist();
+                        warnx("GOT SIGHUP");
                        got_sighup = 0;
                }
                readfds = svc_fdset;

So right now my mountd logs and ignores SIGHUP. Upon a tinderbuild I can see a lot of "GOT SIGHUP" messages in mountd debug log.

How can I find - which process is sending HUP signal to mountd? I tried to ktrace mountd, but it seems that there is no way to determine signal source:

Code: 
 94370 mountd   RET   select -1 errno 4 Interrupted system call
 94370 mountd   PSIG  SIGHUP caught handler=0x402bb0 mask=0x0 code=0x0
 94370 mountd   CALL  sigreturn(0x7fffffffe460)
 94370 mountd   RET   sigreturn JUSTRETURN
 94370 mountd   CALL  write(0x2,0x7fffffffe140,0x8)
 94370 mountd   GIO   fd 2 wrote 8 bytes
       "mountd: "
 94370 mountd   RET   write 8
 94370 mountd   CALL  write(0x2,0x7fffffffe220,0xa)
 94370 mountd   GIO   fd 2 wrote 10 bytes
       "GOT SIGHUP"
 
FlyDrag said:
How can I find - which process is sending HUP signal to mountd? I tried to ktrace mountd, but it seems that there is no way to determine signal source:
Click to expand...

Today I got an idea. Which process is the best candidate? Of course - /sbin/mount.

Code: 
        /*
         * If the mount was successfully, and done by root, tell mountd the
         * good news.
         */
        if (rval == 0 && getuid() == 0)
                restart_mountd();

So, this problem is not related to ZFS at all and should exists in all nfs server installations. But it seems to be extremely uncommon to have nfsd and tinderbox running on the same host, and because of this nobody hit this problem before.

And it seems that there is no elegant solution. The only possible solution I have now is a special HUP-ignore switch to mountd. Any better ideas?
 
Sending HUP signal to mountd is a documented mount behavior. According to documentation only mount send HUP signal. All other mount_* utilities don't.

I found a better workaround for my problem. I patched tinderbox to use mount_nullfs instead of mount and this helps. Right now tinderbox could build packages without any interaction with mountd.

I'll check how this is working and send PR for tinderbox.
 
You must log in or register to reply here.
Back
Top