Red Hat Bugzilla – Bug 886041
mount fails silently when talking to wrong server version (XDR decoding error)
Last modified: 2014-08-11 19:22:35 EDT
Description of problem:
mount fails silently (return code 0, nothing reported) under certain error conditions.
The particular condition which reproduces this was where a client machine wrongly had 3.2.5 installed, and was trying to talk to a 3.3.1 server. If you look in gluster client logs, you see "XDR decoding error".
However the mount command showed no error, and the return code from mount was 0, so there was no indication of any problem (except that the mount didn't actually take place of course)
Version-Release number of selected component (if applicable):
Linux ar48 3.2.0-34-generic #53-Ubuntu SMP Thu Nov 15 10:48:16 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
Ubuntu 12.04 LTS x86_64
client: glusterfs-3.2.5 from Ubuntu repo
server: glusterfs-3.3.1 from semiosis PPA
Steps to Reproduce:
1. configure server running glusterfs-3.3.1
2. configure client with glusterfs-3.2.5
3. mount -t glusterfs server1:/data /gluster/data
mount returns to the command line, echo $? shows 0
Error message to be displayed, and echo $? to show value >0
$ tail /var/log/glusterfs/gluster-data.log
[2012-12-11 10:37:18.18194] I [glusterfsd.c:1493:main] 0-/usr/sbin/glusterfs: Started running /usr/sbin/glusterfs version 3.2.5
[2012-12-11 10:37:18.40878] E [glusterfsd-mgmt.c:621:mgmt_getspec_cbk] 0-glusterfs: XDR decoding error
[2012-12-11 10:37:18.40932] E [glusterfsd-mgmt.c:695:mgmt_getspec_cbk] 0-mgmt: failed to fetch volume file (key:/data)
[2012-12-11 10:37:18.41051] W [glusterfsd.c:727:cleanup_and_exit] (-->/usr/lib/libgfrpc.so.0(rpc_clnt_notify+0x7d) [0x7f2856e5084d] (-->/usr/lib/libgfrpc.so.0(rpc_clnt_handle_reply+0xa5) [0x7f2856e4fec5] (-->/usr/sbin/glusterfs(mgmt_getspec_cbk+0x2fd) [0x7f28574e7e3d]))) 0-: received signum (0), shutting down
[2012-12-11 10:37:18.41074] I [fuse-bridge.c:3727:fini] 0-fuse: Unmounting '/gluster/data'.
Thanks for the report. The issue of not returning the proper error code was fixed only in 3.4.0 releases (ie, master branch). if you use 3.4.0qa4 now, it should be fixed.