Hide Forgot
Following error message seen at nfs-server log file. [2010-09-18 03:45:31.570388] E [client-handshake.c:730:client_query_portmap_cbk] aws18-client-0: failed to get the port number for remote subvolume [2010-09-18 03:45:31.575514] E [client-handshake.c:730:client_query_portmap_cbk] aws18-client-3: failed to get the port number for remote subvolume [2010-09-18 03:45:31.590656] E [client-handshake.c:730:client_query_portmap_cbk] aws18-client-2: failed to get the port number for remote subvolume but showmount -e works fine from all server and clients.
Please update the status of this bug as its been more than 6months since its filed (bug id < 2000) Please resolve it with proper resolution if its not valid anymore. If its still valid and not critical, move it to 'enhancement' severity.
Steps to reproduce > stop the volume > killall glusterd > start glusterd > start the volume After this you will get the above error message in nfs.log file. - If nfs.kernel.server is started, you will error message when you are mounting it on nfs saying , access is denied - Otherwise you won't have problem with that error as far as i have observed.
seeing this log in nfs.log file just after nfs server process started is a valid behavior in the current design of how NFS process is started when one does 'volume start'. operations which happen in order here (w.r.t two threads). proc 1 (brick-glusterfsd): started with '-s' and will do a 'portmap_signin' once init properly happens. proc 2 (nfs - glusterfs) ; started directly with the volume file, and during the initialization of 'protocol/client', the rpc tries to connect to 'glusterd' first and queries for the port for which it should connect to. By the time this request is made, the portmap-signin from the 'proc1' would have not yet happened, which results in this error log. If it is shown only one or two time during the initialization part, then this bug should be closed as invalid, because with current design this will be happening.