While testing rolling upgrades from 3.3 to 3.4, I ran into the "Transport
Endpoint is not connected" issue on my test client (running 3.3) after
rebooting two of my four test GlusterFS 3.4 servers
(distributed-replicated-2).
Unmounting and remounting the volume was the only way I could get the error
to go away
As the nodes in question were actually up at the time I got the error, and
waiting did not help, I checked the client logs and found this:
[2014-03-04 23:19:26.124162] E [dht-common.c:1374:dht_lookup] 0-TEST1-dht:
Failed to get hashed subvol for /
[2014-03-04 23:19:26.124434] E [dht-common.c:1374:dht_lookup] 0-TEST1-dht:
Failed to get hashed subvol for /
[2014-03-04 23:19:27.626845] I [afr-common.c:3843:afr_local_init]
0-TEST1-replicate-0: no subvolumes up
[2014-03-04 23:19:27.626928] W [fuse-bridge.c:2525:fuse_statfs_cbk]
0-glusterfs-fuse: 77: ERR => -1 (Transport endpoint is not connected)
[2014-03-04 23:19:27.857455] E [common-utils.c:125:gf_resolve_ip6]
0-resolver: getaddrinfo failed (No address associated with hostname)
[2014-03-04 23:19:27.857507] E
[name.c:243:af_inet_client_get_remote_sockaddr] 0-TEST1-client-0: DNS
resolution failed on host glustertest1
[2014-03-04 23:19:28.047913] E [common-utils.c:125:gf_resolve_ip6]
0-resolver: getaddrinfo failed (No address associated with hostname)
[2014-03-04 23:19:28.047963] E
[name.c:243:af_inet_client_get_remote_sockaddr] 0-TEST1-client-1: DNS
resolution failed on host glustertest2
These log messages are interesting because although the servers in question
(glustertest{1,2,3,4} are not in DNS, they *are* in the /etc/hosts files on
all of the hosts in question.
Is it a bug that the client requires that all the GlusterFS servers be in
DNS?
--
Justin Dossey
CTO, PodOmatic
_______________________________________________
Gluster-users mailing list
[email protected]
http://supercolony.gluster.org/mailman/listinfo/gluster-users
