Does anyone have compiled solaris 8 binaries they can send me? My efforts to compile ganglia on solaris 8 with gcc did not get very far. Not to sure why but if someone can send me the binaries, that would make me a happy puppy.
kind regards, Richard ps, if interested: Making all in examples /bin/bash ../libtool --mode=link gcc -g -O2 -L../src/ -o simple simple.o ../src/libconfuse.la gcc -g -O2 -o simple simple.o -L/var/tmp/rg/ganglia-3.0.2/srclib/confuse/src ../src/.libs/libconfuse.a Undefined first referenced symbol in file cfg_scan_string_end ../src/.libs/libconfuse.a(confuse.o) cfg_scan_fp_begin ../src/.libs/libconfuse.a(confuse.o) cfg_scan_string_begin ../src/.libs/libconfuse.a(confuse.o) cfg_scan_fp_end ../src/.libs/libconfuse.a(confuse.o) cfg_yyin ../src/.libs/libconfuse.a(confuse.o) cfg_yylex ../src/.libs/libconfuse.a(confuse.o) cfg_lexer_include ../src/.libs/libconfuse.a(confuse.o) ld: fatal: Symbol referencing errors. No output written to simple collect2: ld returned 1 exit status *** Error code 1 make: Fatal error: Command failed for target `simple' ----------------------------------------------------------------------------------------- -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Martin Knoblauch Sent: 30 November 2005 09:46 To: Ramon Bastiaans Cc: Markus "Törnqvist; [email protected] Subject: Re: [Ganglia-general] Unicast issue Hi, some more info: - udp_send_channel does not have a "bind" attribute, just forget my comment below. Looking at the code sometimes helps. - udp_recv_channel: if you specify "mcast_join" and "bind" with different IP adresses, no unicast processing will take place (from the gmond.conf man page) And forget the comment about "localhost". It is a bit more complicated like that.... Martin --- Martin Knoblauch <[EMAIL PROTECTED]> wrote: > Ramon, Markus, > > actually, below one works fine for me. The same config file is used > on all gmond-hosts in the cluster (actually pretty beautiful :-). > > - host "172.17.17.103" receives the metrics from all participating > gmonds. > - all other hosts will report empty metrics if queried. If you want > them to report their own metrics, add a upd_send_channel for > "localhost. > - host "172.17.33.108" is the only one allowed to query the TCP port. > This is the host where gmetad would be running (no gmond necessary on > this host). If you leave out the "acl" all hosts may query the TCP > port. > > The "bind" in the udp_recv_channel maybe needed if you have more than > one network interface and the traffic does not come on the first one. > For the upd-send-channel, no bind should ever be *neccessary*. But I > am > really not sure about this. > > > -------------------------------- > udp_send_channel { > host = 172.17.17.103 > port = 9649 > } > > udp_recv_channel { > port = 9649 > } > > tcp_accept_channel { > acl { > default = "deny" > access { > ip = 172.17.33.108 > mask = 32 > action = "allow" > } > } > port = 9649 > } > ------------------------- > > Cheers > Martin > > --- Ramon Bastiaans <[EMAIL PROTECTED]> wrote: > > > Actually, bind is needed to specify what local ip to bind to and > > listen on in a unicast setup. > > mcast_join is used when listening to multicasting. > > > > However, why are you using 2 different ip adresses in the recv and > > send channel? This will never work. > > You need to set you send channel to the same ip/port as your recv > > channel. > > Else you are sending the information to 1 place and listening for > > that > > information on another place. > > > > Kind regards, > > - Ramon. > > > > Martin Knoblauch wrote: > > > > >Markus, > > > > > > if you want unicast, I would leave out the "bind" thing. That is > > for > > >multicast, AFAIK. > > > > > >telnet w.x.y.z 8649 > > > > > >Should give you a correct list of metrices. > > > > > >Cheers > > >Martin > > > > > >--- Markus Törnqvist <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > >>Hi! > > >> > > >>I'm experiencing the weirdest issue here with unicasting; not > even > > >>the mail archives helped so I hope someone here can give me a > hand. > > >> > > >>Shouldn't it suffice to have the config file look like this: > > >>udp_send_channel { > > >> host = w.x.y.z > > >> port = 8649 > > >>} > > >> > > >>udp_recv_channel { > > >> bind = w2.x2.y2.z2 > > >> port = 8649 > > >>} > > >> > > >>for those parts? > > >> > > >>Nothing anywhere that points to multicasts? > > >> > > >>Right now, with that kind of configuration, I get an empty result > > >>set; <GANGLIA_XML VERSION="3.0.2" SOURCE="gmond"> > > >><CLUSTER NAME="unspecified" LOCALTIME="1133291540" > > >>OWNER="unspecified" LATLONG="unspecified" URL="unspecified"> > > >></CLUSTER> > > >></GANGLIA_XML> > > >>Connection closed by foreign host. > > >> > > >>It's somewhat annoying because we can't use multicast really and > > even > > >>if > > >>we did it seems some very faux IPs are sent back, which may be > > >>another error on my part, but irrelevant if it's due to > > >>multicasting.. > > >> > > >>Any help is highly appreciated, thanks! > > >> > > >>-- > > >>mjt > > >> > > >> > > >> > > >> > > > > > > > > >------------------------------------------------------ > > >Martin Knoblauch > > >email: k n o b i AT knobisoft DOT de > > >www: http://www.knobisoft.de > > > > > > > > >------------------------------------------------------- > > >This SF.net email is sponsored by: Splunk Inc. Do you grep through > > log files > > >for problems? Stop! Download the new AJAX search engine that > makes > > >searching your log files as easy as surfing the web. DOWNLOAD > > SPLUNK! > > >http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click > > >_______________________________________________ > > >Ganglia-general mailing list [email protected] > > >https://lists.sourceforge.net/lists/listinfo/ganglia-general > > > > > > > > > > -- > > .--------------------------------------------. > > | ing. Ramon Bastiaans | > > | HPC - Systems Programmer | > > |--------------------------------------------| > > | SARA - Computing and Networking Services | > > | Kruislaan 415 PO Box 194613 | > > | 1098 SJ Amsterdam 1090 GP Amsterdam | > > |--------------------------------------------| > > | Mail: bastiaans ( a t ) sara ( d o t ) nl | > > | Web: http://www.sara.nl/ | > > | Phone: +31 (0)20 592 80 19 | > > | Fax: +31 (0)20 668 31 67 | > > `--------------------------------------------' > > > > > > > ------------------------------------------------------ > Martin Knoblauch > email: k n o b i AT knobisoft DOT de > www: http://www.knobisoft.de > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log > files for problems? Stop! Download the new AJAX search engine that > makes searching your log files as easy as surfing the web. DOWNLOAD > SPLUNK! > http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click > _______________________________________________ > Ganglia-general mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/ganglia-general > > ------------------------------------------------------ Martin Knoblauch email: k n o b i AT knobisoft DOT de www: http://www.knobisoft.de ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click _______________________________________________ Ganglia-general mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ganglia-general ------------------------------------------------------------------------ For more information about Barclays Capital, please visit our web site at http://www.barcap.com. Internet communications are not secure and therefore the Barclays Group does not accept legal responsibility for the contents of this message. Although the Barclays Group operates anti-virus programmes, it does not accept responsibility for any damage whatsoever that is caused by viruses being passed. Any views or opinions presented are solely those of the author and do not necessarily represent those of the Barclays Group. Replies to this email may be monitored by the Barclays Group for operational or business reasons. ------------------------------------------------------------------------
