I was trying to figure out how glusterd starts. Since it is the same binary as glusterfsd, it calls create_fuse_mount(). This quickly returns 0 if no mount point was specified, but if you did specify a mount point, it ends up making that directory a fuse mount. Any command on that directory hangs (for obvious reasons). Now, I got a bit adventurous and ran glusterd as below: # glusterd /var and lo, every command after that hung up. The window manager wouldn't do many useful things. I had a root shell handy, but reboot wouldn't proceed. I had to forcefully power down the system to get out of this scenario. Bad! We need to be careful about when to call create_fuse_mount(). We've got to be more defensive than depend on (the absence of) a variable to determine whether to call it or not.
'mount' should happen only when 'glusterfs' option is given. If not the last argument should not be treated as mountpoint.
This patch should fix the problem http://patches.gluster.com/patch/7961/
A bug gets resolved only after the patch is committed to the source repository. Keep it open till it gets committed.
CHANGE: http://review.gluster.com/5 (create_fuse_mount() now checks if it is a client process before performing) merged in master by Anand Avati (avati)
Tested with the mainline. gave glusterfsd <mount_point>, and did df -h, there was no hang and no message saying transport endpoint not connected. Tried with glusterd <mount point> and got the same results. Tried with glusterfs <mount point> and when I did df it said transport endpoint not connected (which is the expected result).
Few suggestions: glusterfsd.c:main * Instead of calling create_fuse_mount and making checks on process_mode, call create_fuse_mount only if process_mode is client process. glusterfsd.c:create_fuse_mount * If mount point is not present, don't log it as a TRACE log, user has to know why mount failed.