On Thu, Mar 03, 2005 at 09:05:34AM +, Stu Teasdale wrote:
> Hi all,
>
> I'm currently working on ganglia 3.0.0 packages for Debian and have a
> small query. Debian general policy states that external libraries should
> be dynamically linked to executables, and the dependency system ensures
kumar-
you are not the first person to have this problem. the workaround is to
set the timeout on the tcp_accept_channel to -1. for example,
tcp_accept_channel {
...
...
timeout = -1
}
this will tell gmond to use blocking io which will prevent truncating of
the xml data.
good luck!
and i forgot to add one more thing about using ./srclib.
if you take a look at ./lib/apr_net.[c,h], you'll see that i need direct
access to apr code in order to operate directly on apr network
structures in order to support multicast (since apr doesn't support
multicast). i couldn't do think
stu-
the reason that i statically link in apr/confuse/expat is manifold.
there are people who are running ganglia on 2000 node clusters and
tracking dependencies can be a nightmare at that scale. having a single
statically-linked executable and a config file to sync up is simple.
static lin
Hello
I was using the older version of ganglia (2.5.4). The paarameter filter
on the node only drive me to the new version of ganglia ie 3.0.0. I
compiled it and updated the whole cluster with gmond 3.0.0. when I tried
to run the run the gmetad it stops. finally I checked the gmetad in
debug
Hi all,
I'm currently working on ganglia 3.0.0 packages for Debian and have a
small query. Debian general policy states that external libraries should
be dynamically linked to executables, and the dependency system ensures
that this isn't a major issue for users, but I notice that ganglia 3
se
