It means you can't query that gmond directly for the metric data. It would
have to forward its metrics to another gmond that has the TCP accept
channel configured and can be queried for metric data of itself and other
gmonds.

--Nick.

On Thu, Nov 29, 2012 at 2:07 PM, Langton <langt...@eclipseholdings.co.za>wrote:

>  I have commented out the tcp_accept_channel and it seems its running
> fine. what are the impacts running ganglia without the tcp channel
>
>
> On 29/11/2012 15:11, Nicholas Satterly wrote:
>
> It's not a bug. You can't have more than one gmond listening on the same
> TCP port.
>
>  So if you already have a gmond running and listening on TCP port 8649
> you must choose another port number for the second one. And make sure that
> one isn't being used by something else.
>
>  --Nick.
>
> On Thu, Nov 29, 2012 at 12:47 PM, Langton 
> <langt...@eclipseholdings.co.za>wrote:
>
>>  [root@cnode-1-23 ~]# lsof -i tcp:8649
>>
>> COMMAND   PID    USER   FD   TYPE  DEVICE SIZE/OFF NODE NAME
>> gmond   12878 ganglia    5u  IPv4 1546198      0t0  TCP *:8649 (LISTEN)
>>
>> only one instance of gmond is running. Wonder if its a bug
>>
>>
>>
>> On 29/11/2012 13:58, Nicholas Satterly wrote:
>>
>> Something else is already bound to TCP port 8649...
>>
>>  sin_addr=inet_addr("0.0.0.0")}, 16) = -1 EADDRINUSE (Address already in
>> use)
>>
>> You can run "lsof -i tcp:8649" as root to see what it is. It's most
>> probably another "gmond".
>>
>>  --Nick.
>>
>> On Thu, Nov 29, 2012 at 7:25 AM, Langton 
>> <langt...@eclipseholdings.co.za>wrote:
>>
>>> Thank you but if I uncomment the tcp channel it shows me the following
>>> error
>>>
>>>     [root@cnode-1-23 ~]# gmond -d10
>>>
>>>     loaded module: core_metrics
>>>
>>>     loaded module: cpu_module
>>>
>>>     loaded module: disk_module
>>>
>>>     loaded module: load_module
>>>
>>>     loaded module: mem_module
>>>
>>>     loaded module: net_module
>>>
>>>     loaded module: proc_module
>>>
>>>     loaded module: sys_module
>>>
>>>     loaded module: multicpu_module
>>>
>>>     udp_recv_channel mcast_join=239.2.11.71 mcast_if=NULL port=8649
>>>     bind=239.2.11.71
>>>
>>>      tcp_accept_channel bind=NULL port=8649
>>>
>>>     Unable to create tcp_accept_channel. Exiting.
>>>
>>>
>>>  A trace gives me the following output
>>>
>>> [root@cnode-1-23 ~]#strace gmond -d10
>>>
>>> ....
>>> ....
>>> ioctl(4, SIOCGIFADDR, {ifr_name="eth0", ifr_addr={AF_INET,
>>> inet_addr("172.17.200.23")}}) = 0
>>> setsockopt(4, SOL_IP, IP_ADD_MEMBERSHIP, "\357\2\vG\254\21\310\27", 8) =
>>> 0
>>> epoll_ctl(3, EPOLL_CTL_ADD, 4, {EPOLLIN, {u32=147155552,
>>> u64=147155552}}) = 0
>>> write(2, "tcp_accept_channel bind=NULL por"..., 38tcp_accept_channel
>>> bind=NULL port=8649) = 38
>>> write(2, "\n", 1
>>> )                       = 1
>>> socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 5
>>> setsockopt(5, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
>>> bind(5, {sa_family=AF_INET, sin_port=htons(8649),
>>> sin_addr=inet_addr("0.0.0.0")}, 16) = -1 EADDRINUSE (Address already in
>>> use)
>>> close(5)                                = 0
>>> write(2, "Unable to create tcp_accept_chan"..., 47Unable to create
>>> tcp_accept_channel. Exiting.
>>>
>>> ) = 47
>>> close(4)                                = 0
>>> close(3)                                = 0
>>> munmap(0x2b411a580000, 2123232)         = 0
>>> munmap(0x2b411a360000, 2224704)         = 0
>>> munmap(0x2b411a141000, 2223520)         = 0
>>> munmap(0x2b4119f22000, 2224128)         = 0
>>> munmap(0x2b4119d02000, 2224992)         = 0
>>> munmap(0x2b4119ae3000, 2223808)         = 0
>>> munmap(0x2b41198c4000, 2223840)         = 0
>>> munmap(0x2b41196a4000, 2226144)         = 0
>>> exit_group(1)                           = ?
>>>
>>>
>>>
>>>
>>>
>>> Regards
>>>
>>> Langton
>>>
>>>
>>> On 28/11/2012 22:56, Nicholas Satterly wrote:
>>> > The TCP accept channel port is commented out in your config file.
>>> > Remove the hash in front of "port = 8649" and try again.
>>> >
>>> > --Nick.
>>> >
>>> > On 28 Nov 2012, at 07:09, Langton <langt...@eclipseholdings.co.za>
>>> wrote:
>>> >
>>> >> Gmond clients become inactive after a while of starting the gmond
>>> service.
>>> >>
>>> >> Find below the error.
>>> >>
>>> >> [root@hostname ~]# gmond -d10
>>> >> loaded module: core_metrics
>>> >> loaded module: cpu_module
>>> >> loaded module: disk_module
>>> >> loaded module: load_module
>>> >> loaded module: mem_module
>>> >> loaded module: net_module
>>> >> loaded module: proc_module
>>> >> loaded module: sys_module
>>> >> loaded module: multicpu_module
>>> >> udp_recv_channel mcast_join=239.2.11.71 mcast_if=NULL port=8649
>>> >> bind=239.2.11.71
>>> >> tcp_accept_channel bind=NULL port=-1
>>> >> Unable to create tcp_accept_channel. Exiting.
>>> >>
>>> >>
>>> >>
>>> >>
>>> >> [root@hostname ~]#cat /etc/ganglia/gmond.conf
>>> >>
>>> >>
>>> >>
>>> >> globals {
>>> >>  daemonize = yes
>>> >>  setuid = yes
>>> >>  user = ganglia
>>> >>  debug_level = 0
>>> >>  max_udp_msg_len = 1472
>>> >>  mute = no
>>> >>  deaf = no
>>> >>  allow_extra_data = yes
>>> >>  host_dmax = 86400 /*secs */
>>> >>  cleanup_threshold = 300 /*secs */
>>> >>  gexec = no
>>> >>  send_metadata_interval = 30 /*secs */
>>> >> }
>>> >>
>>> >> /*
>>> >> * The cluster attributes specified will be used as part of the
>>> <CLUSTER>
>>> >> * tag that will wrap all hosts collected by this instance.
>>> >> */
>>> >> cluster {
>>> >>  name = "cluster"
>>> >>  owner = "unspecified"
>>> >>  latlong = "unspecified"
>>> >>  url = "unspecified"
>>> >> }
>>> >>
>>> >> /* The host section describes attributes of the host, like the
>>> location */
>>> >> host {
>>> >>  location = "unspecified"
>>> >> }
>>> >>
>>> >> /* Feel free to specify as many udp_send_channels as you like.  Gmond
>>> >>   used to only support having a single channel */
>>> >> udp_send_channel {
>>> >>  bind_hostname = yes # Highly recommended, soon to be default.
>>> >>                       # This option tells gmond to use a source
>>> address
>>> >>                       # that resolves to the machine's hostname.
>>>  Without
>>> >>                       # this, the metrics may appear to come from any
>>> >>                       # interface and the DNS names associated with
>>> >>                       # those IPs will be used to create the RRDs.
>>> >>  mcast_join = 239.2.11.71
>>> >>  #host = 172.17.203.43
>>> >>  port = 8649
>>> >>  ttl = 1
>>> >> }
>>> >>
>>> >> /* You can specify as many udp_recv_channels as you like as well. */
>>> >> udp_recv_channel {
>>> >>   mcast_join = 239.2.11.71
>>> >>   port = 8649
>>> >>   bind = 239.2.11.71
>>> >> }
>>> >>
>>> >> /* You can specify as many tcp_accept_channels as you like to share
>>> >>   an xml description of the state of the cluster */
>>> >> tcp_accept_channel {
>>> >> #   port = 8649
>>> >> }
>>> >>
>>> >> Thank you so much for your help
>>> >>
>>> >> Regars
>>> >>
>>> >> Langton
>>> >>
>>> >>
>>> ------------------------------------------------------------------------------
>>> >> Keep yourself connected to Go Parallel:
>>> >> INSIGHTS What's next for parallel hardware, programming and related
>>> areas?
>>> >> Interviews and blogs by thought leaders keep you ahead of the curve.
>>> >> http://goparallel.sourceforge.net
>>> >> _______________________________________________
>>> >> Ganglia-general mailing list
>>> >> Ganglia-general@lists.sourceforge.net
>>> >> https://lists.sourceforge.net/lists/listinfo/ganglia-general
>>>
>>>
>>
>>
>
>
------------------------------------------------------------------------------
Keep yourself connected to Go Parallel: 
VERIFY Test and improve your parallel project with help from experts 
and peers. http://goparallel.sourceforge.net
_______________________________________________
Ganglia-general mailing list
Ganglia-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ganglia-general

Reply via email to