<div dir="ltr"><div><div><div><div>Apparently something common in my OmniOS setup is triggering this.   I have no idea what yet, and I'm feeling green at digging through this issue.   <br><br></div>On one of my VMs for doing script development, I exported the data pool planing to test importing it with a different cache location and the problem immediately happened.   Now I cannot get nlockmgr to start at all on this VM.   I tried disabling all nfs services and re-enabling.  Still failing with /usr/lib/nfs/lockd[862]: [ID 491006 daemon.error] Cannot establish NLM service over <file desc. 9, protocol udp> : I/O error. Exiting<br><br>root@ZFSsendTest1:/root# svcs -a|grep nfs<br>disabled       13:47:05 svc:/network/nfs/log:default<br>disabled       13:47:11 svc:/network/nfs/rquota:default<br>disabled       13:55:05 svc:/network/nfs/server:default<br>disabled       13:55:32 svc:/network/nfs/nlockmgr:default<br>disabled       13:55:32 svc:/network/nfs/mapid:default<br>disabled       13:55:32 svc:/network/nfs/status:default<br>disabled       13:55:32 svc:/network/nfs/client:default<br>disabled       13:55:57 svc:/network/nfs/cbd:default<br>root@ZFSsendTest1:/root# svcadm enable svc:/network/nfs/status:default svc:/network/nfs/cbd:default svc:/network/nfs/mapid:default svc:/network/nfs/server:default svc:/network/nfs/nlockmgr:default<br>root@ZFSsendTest1:/root# svcs -a|grep nfs<br>disabled       13:47:05 svc:/network/nfs/log:default<br>disabled       13:47:11 svc:/network/nfs/rquota:default<br>disabled       13:55:32 svc:/network/nfs/client:default<br>online         13:56:56 svc:/network/nfs/status:default<br>online         13:56:56 svc:/network/nfs/cbd:default<br>online         13:56:56 svc:/network/nfs/mapid:default<br>offline        13:56:56 svc:/network/nfs/server:default<br>offline*       13:56:56 svc:/network/nfs/nlockmgr:default<br>root@ZFSsendTest1:/root# svcs -a|grep nfs<br>disabled       13:47:05 svc:/network/nfs/log:default<br>disabled       13:47:11 svc:/network/nfs/rquota:default<br>disabled       13:55:32 svc:/network/nfs/client:default<br>online         13:56:56 svc:/network/nfs/status:default<br>online         13:56:56 svc:/network/nfs/cbd:default<br>online         13:56:56 svc:/network/nfs/mapid:default<br>offline        13:56:56 svc:/network/nfs/server:default<br>maintenance    13:58:11 svc:/network/nfs/nlockmgr:default<br><br></div>This VM has never had RSF-1 on it, so that definitely isn't the trigger.  This VM has never exhibited this problem before today.  It has been rebooted many times.   <br><br>I wonder if the problem is triggered by exporting a pool with NFS exports that have active client connections.   That is always the case on my production systems.   This VM has one NFS client that was connected when I exported the pool.<br><br></div><div>Now nlockmgr dies and goes to maintenance mode regardless if I import the data pool or not.<br></div><div><br></div>Any advice on where to dig for better diagnosis of this would be helpful.   If any developers would like to get access to this VM I'd be happy to arrange that too.<br><br></div>-Chip<br><div><div><div><div><div><br></div></div></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Oct 10, 2014 at 9:26 AM, Richard Elling <span dir="ltr"><<a href="mailto:richard.elling@richardelling.com" target="_blank">richard.elling@richardelling.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><span class=""><div><div><div><br></div></div></div><div>On Oct 10, 2014, at 6:15 AM, "Schweiss, Chip" <<a href="mailto:chip@innovates.com" target="_blank">chip@innovates.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct 9, 2014 at 9:54 PM, Dan McDonald <span dir="ltr"><<a href="mailto:danmcd@omniti.com" target="_blank">danmcd@omniti.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span><br>
On Oct 9, 2014, at 10:23 PM, Schweiss, Chip <<a href="mailto:chip@innovates.com" target="_blank">chip@innovates.com</a>> wrote:<br>
<br>
> Just tried my 2nd system.   r151010 nlockmgr starts after clearing maintenance mode.   r151012 it will not start at all.  nfs/status was enabled and online.<br>
><br>
> The commonality I see on the two systems I have tried is they are both part of an HA cluster.   So they don't import the pool at boot, but RSF-1 imports it with cache mapped to a different location.<br>
<br>
</span>That could be something HA Inc. needs to further test.  We don't directly support RSF-1, after all.<br>
<span><br></span></blockquote><div><br></div><div>I there really isn't anything different than an auto imported pool.  I'm suspecting using an alternate cache location my be triggering something else to go wrong in the nlockmgr.   <br></div></div></div></div></div></blockquote><div><br></div></span>no, these are totally separate subsystems. RSF-1 imports the pool. NFS sharing is started by the zpool command, in userland, via sharing after the dataset is mounted. You can do the same procedure manually... no magic pixie dust needed. <div><br></div><div><span class=""><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>Here's the command RSF-1 uses to import the pool:<br>zpool import -c /opt/HAC/RSF-1/etc/volume-cache/nrgpool.cache -o cachefile=/opt/HAC/RSF-1/etc/v<br>olume-cache/nrgpool.cache-live -o failmode=panic  nrgpool<br><br></div><div>After the pool import it  puts the ip addresses back and is done.   That happens in less than 1 second.<br><br></div><div>In the mean time NFS services auto start and nlockmgr starts spinning.<br></div></div></div></div></div></blockquote><div><br></div></span><div>Perhaps share doesn't properly start all of the services? Does it work ok if you manually "svcadm enable" all of the NFS services?</div><span class="HOEnZb"><font color="#888888"><div><br><br>  -- richard</div></font></span><span class=""><br><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span>
> nlockmgr is becoming a real show stopper.<br>
<br>
</span>svcadm disable nlockmgr nfs/status<br>
svcadm enable nfs/status<br>
svcadm enable nlockmgr<br>
<br>
You may wish to discuss this on illumos as well, I'm not sure who all else is seeing this save me one time, and you seemingly a lot of times.<br></blockquote><div><br></div><div>I did that this time, no joy.   Today I'm working on a virtual setup with HA to see if I can get this reproduced on r151012.   <br><br></div><div>I thought this nlockmgr propblem was related to lots of nfs exports until, I ran into this on my SSD pool.  It used to be able to fail over in about 3-5 seconds.   It takes nlockmgr now sits in a spinning state for a few minutes and fails every time.   A clear of the maintenance mode, brings it back nearly instantly.   This is on r151010.  On r151012 it fails every time.   <br><br></div><div>Hopefully I can reproduce and I'll start a new thread copying Illumos too.<br><br></div><div>-Chip</div><br></div><br></div></div>
</div></blockquote></span><span class=""><blockquote type="cite"><div><span>_______________________________________________</span><br><span>OmniOS-discuss mailing list</span><br><span><a href="mailto:OmniOS-discuss@lists.omniti.com" target="_blank">OmniOS-discuss@lists.omniti.com</a></span><br><span><a href="http://lists.omniti.com/mailman/listinfo/omnios-discuss" target="_blank">http://lists.omniti.com/mailman/listinfo/omnios-discuss</a></span><br></div></blockquote></span></div></div></blockquote></div><br></div>