Can you try 3.3.0. I'm running
Red Hat Enterprise Linux Server release 6.1 (Santiago)
2.6.32-131.12.1.el6.x86_64
Vladimir
On Thu, 9 Feb 2012, drich wrote:
In doing some more debugging I'm still stumped. It runs, it's listening on
8649, then it isn't. Running with debug turned
doesn't show any errors or unusual messages, just a sudden:
tcp_accept_channel bind=NULL port=8649
Unable to create tcp_accept_channel. Exiting.
after it runs for almost exactly 1 minute.
Running an strace against it I see the following:
[pid 9223] 13:27:05.118581 socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 3
[pid 9223] 13:27:05.118638 fcntl(3, F_GETFD) = 0
[pid 9223] 13:27:05.118676 fcntl(3, F_SETFD, FD_CLOEXEC) = 0
[pid 9223] 13:27:05.118770 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
[pid 9223] 13:27:05.118825 bind(3, {sa_family=AF_INET, sin_port=htons(8649),
sin_addr=inet_addr("0.0.0.0")}, 16) = 0
[pid 9223] 13:27:05.118914 listen(3, 5) = 0
[pid 9223] 13:27:05.118976 epoll_ctl(4, EPOLL_CTL_ADD, 3, {EPOLLIN,
{u32=20280952, u64=20280952}}) = 0
[pid 9223] 13:27:05.119109 socket(PF_NETLINK, SOCK_RAW, 0) = 5
[pid 9223] 13:27:05.119139 bind(5, {sa_family=AF_NETLINK, pid=0,
groups=00000000}, 12) = 0
[pid 9223] 13:27:05.119165 getsockname(5, {sa_family=AF_NETLINK, pid=9223,
groups=00000000}, [12]) = 0
...
[pid 9223] 13:28:05.127936 <... epoll_wait resumed> {}, 1, 9833) = 0
[pid 9223] 13:28:05.128170 socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 7
[pid 9223] 13:28:05.128511 fcntl(7, F_GETFD) = 0
[pid 9223] 13:28:05.128748 fcntl(7, F_SETFD, FD_CLOEXEC) = 0
[pid 9223] 13:28:05.129022 setsockopt(7, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
[pid 9223] 13:28:05.129325 bind(7, {sa_family=AF_INET, sin_port=htons(8649),
sin_addr=inet_addr("0.0.0.0")}, 16) = -1
EADDRINUSE (Address already in use)
[pid 9223] 13:28:05.129525 close(7) = 0
[pid 9223] 13:28:05.129649 write(1, "[multi_traffic] Received the fol"...,
77[multi_traffic] Received the following
parameters
{'target_device0': 'eth0'}
) = 77
[pid 9223] 13:28:05.129682 write(2, "Unable to create tcp_accept_chan"...,
47Unable to create tcp_accept_channel. Exiting.
But the socket is already open because pid 9223 opened it much earlier in the
trace (at 13:27:05).
On 09.02.2012 12:29, drich wrote:
Weird, I'm seeing it on two different machines (all that we've installed
it on at this point). Both installed
with the same RPM. The RPM was built by simply extracting the spec file
from the source tarball and running
rpmbuild -ba on it.
This is running on RHEL 6.2 just reinstalled last Wed (our weekly devel
build). The kernel is
2.6.32-220.4.1.el6.x86_64.
I'll see if I can track down a system that wasn't kickstarted this week,
if I can it should still be running 6.1
and I can see if I see the same behavior there.
On 09.02.2012 11:32, Vladimir Vuksan wrote:
I have been testing 3.3.1 on RHEL6 and I haven't seen this issue. I
actually kicked off a new VM just now, built RPMS from scratch and it's
working correctly.
Vladimir
On Thu, 9 Feb 2012, drich wrote:
I am starting to test Ganglia 3.3.1 on RedHat Enterprise 6,
but have run into a problem.
When I attempt to use the same configuration that worked
under 3.1.1 everything works
fine for a minute or two, but then gmond dies with the error:
Unable to create
tcp_accept_channel. Exiting.#012. The strangest thing is that
it works fine for those
first minutes, forwarding data off to my collector and
responding to requests on the
tcp_accept_channel. Does gmond try and reopen the socket,
potentially with a race
condition where it opens it before it closes completely? Does
anyone know of anything
else that changed in 3.3.1 that could be causing this? The
config is about as simple as
it gets for the accept_channel: tcp_accept_channel { port =
8649 } If I comment that
out gmond works just fine (except that I can't query it
directly, of course). Any ideas?
-- Dan Rich <dr...@employees.org> http://www.employees.org/~drich/
"Step up to red
alert!" "Are you sure, sir? It means changing the bulb in the
sign..." - Red Dwarf
(BBC)
--
Dan Rich
http://www.employees.org/~drich/
"Step up to red alert!" "Are you sure, sir?
It means changing the bulb in the sign..."
- Red Dwarf (BBC)
--
Dan Rich <dr...@employees.org>
http://www.employees.org/~drich/
"Step up to red alert!" "Are you sure, sir?
It means changing the bulb in the sign..."
- Red Dwarf (BBC)
------------------------------------------------------------------------------
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
_______________________________________________
Ganglia-general mailing list
Ganglia-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ganglia-general
