I notice in configure.in that `lib' is appended to the path supplied for
confuse and other libraries.
However, on a 64 bit Redhat machine, it may be necessary to append lib64
instead. What is the best practice for doing this? I don't think it's
safe to rely on `rpm --eval %_lib', maybe
I've observed a few DNS related issues recently. Currently, gmetad uses
the host names returned in the XML from gmond to create and locate RRDs
for each host.
Some of the problems and possible ideas:
- capitalisation is inconsistent and can even change, RFC specifies that
it is not
I think it's better to use IP to store RRDs. The host names can be
resolved
by webfrontend and cached. The cache can be refreshed by removing old
names,
or edit by hands. For server farms which use kerberos, dns reverse lookup
could returns uninteresting and unfriendly formatted names;
Is there a specific reason why the multicpu module should not be used on
Cygwin builds (or any other static build)?
I found that only some trivial changes were needed to make it compile
and link:
- the static modifier is needed in front of timely_file proc_stat,
otherwise it conflicts with
Jesse Becker wrote:
Got a patch? :)
The static modifier is in bugzilla, #235
http://bugzilla.ganglia.info/cgi-bin/bugzilla/show_bug.cgi?id=235
I wasn't sure about contributing the Makefile patch in case there is
some good reason why it should not be used on Cygwin, hence the question
Hi,
I've just been looking at hash.c, I am testing a fix for bug 232
http://bugzilla.ganglia.info/cgi-bin/bugzilla/show_bug.cgi?id=232
I notice that in some cases, strncmp is used on the key, and in one
case, memcmp is used instead. What is the correct behaviour?
My proposed solution
I've noticed on a large gmetad install (400 clusters) that some of the
data threads get stuck in the CLOSE_WAIT state, and cease polling the
gmonds. Other data threads are running normally. Over time, more and
more of the threads get stuck.
Looking at one of the threads, I found that it
Bernard Li wrote:
Hi Daniel:
On Tue, Jul 7, 2009 at 8:43 AM, Daniel Pocockdan...@pocock.com.au wrote:
I've noticed on a large gmetad install (400 clusters) that some of the
data threads get stuck in the CLOSE_WAIT state, and cease polling the
gmonds. Other data threads are running
Brad Nicholes wrote:
On 7/13/2009 at 8:17 AM, in message
e6ccb7f50907130717i2f3dfd5fi1c69dbd4124a7...@mail.gmail.com, utopia zh
utopia...@gmail.com wrote:
Hi,
While trying to use gmond to monitor our applications, we found some issues:
- Metric collecting may take long time to
I tried to attach this solution to the bug report, but I get this error:
You did not enter a valid attachment number.
Anyhow, this is a solution for bug 232:
http://bugzilla.ganglia.info/cgi-bin/bugzilla/show_bug.cgi?id=232
As a consequence of applying this patch:
- whenever an RRD is
Brad Nicholes wrote:
On 7/16/2009 at 8:07 AM, in message 4a5f3430.20...@pocock.com.au, Daniel
Pocock dan...@pocock.com.au wrote:
I tried to attach this solution to the bug report, but I get this error:
You did not enter a valid attachment number.
Anyhow, this is a solution
Brad Nicholes wrote:
On 7/16/2009 at 9:10 AM, in message 4a5f42d8.9060...@pocock.com.au,
Daniel
Pocock dan...@pocock.com.au wrote:
Brad Nicholes wrote:
On 7/16/2009 at 8:07 AM, in message 4a5f3430.20...@pocock.com.au,
Daniel
Pocock dan
One way to make it non-disruptive for 3.1 would be making this new
behavior configurable (as I suggested in the bug) - is it worth the
extra effort of adding a config option for this, or is 3.2 intended to
be released in the new future?
There isn't a planned date for a 3.2
Is it preferred to raise backport proposals for 3.1 all in a single
email, or start a separate thread for each?
I've just fixed bug 237, this is an essential backport I believe, as it
fixes a seg fault/coding error. (trunk r2006)
My fix for bug 232 is also backwards compatible and safe to
I noticed a few things about mod_gstatus:
- the spec file doesn't include it at all, and deliberately removes the
config file for it
- gmond/modules/Makefile.am excludes it from static builds
Given that Ganglia is modular, is there a good reason for not having
this module in the RPM along
Brad Nicholes wrote:
On 7/28/2009 at 7:27 AM, in message 4a6efcac.4060...@pocock.com.au,
Daniel
Pocock dan...@pocock.com.au wrote:
I noticed a few things about mod_gstatus:
- the spec file doesn't include it at all, and deliberately removes the
config file for it
- gmond
Carlo Marcelo Arenas Belon wrote:
On Mon, Aug 10, 2009 at 09:24:18PM +0100, Daniel Pocock wrote:
I'm making some more changes to trunk over the next few days, some of
them impact the build system (configure.in, Makefile.am).
you mean more than the ones that were already committed
Daniel Pocock wrote:
Carlo Marcelo Arenas Belon wrote:
On Mon, Aug 10, 2009 at 09:24:18PM +0100, Daniel Pocock wrote:
I'm making some more changes to trunk over the next few days, some of
them impact the build system (configure.in, Makefile.am).
you mean more than
Hi,
I've just been looking at Bugzilla to try and establish what is pending
for 3.1.3
I did a search for items that are blocking, critical or major, 12 items
found
Most of them appear to have been there for a while, despite several
other releases. Some of them are no longer bugs.
Is some
Лозгачев Иван Николаевич wrote:
Hello Ganglia-developers,
I try to compile ganglia-3.1.2. Which version of RRDTool should I use?
1.3.X is probably a good choice - particularly if you need the rrdcache
--
Let
Bernard Li wrote:
On Tue, Aug 18, 2009 at 8:22 AM, Brad Nicholesbnicho...@novell.com wrote:
I'm not sure that there has been any definitive issue tracker for releases,
at least not for the 3.1.x releases. The road map going forward has been
basically left up to the community. For
Bernard Li wrote:
Hi Daniel:
On Wed, Aug 19, 2009 at 7:35 AM, Daniel Pocockdan...@pocock.com.au wrote:
I try to compile ganglia-3.1.2. Which version of RRDTool should I use?
1.3.X is probably a good choice - particularly if you need the rrdcache
Has Ganglia been
Bernard Li wrote:
Hi Daniel:
On Wed, Aug 19, 2009 at 11:49 AM, Daniel Pocockdan...@pocock.com.au wrote:
Some of the biggest Ganglia sites I know of probably wouldn't be able to run
without it now
Well, I think the tmpfs hack would still work. But I agree, rrdcached
is a much
Brad Nicholes wrote:
On 8/19/2009 at 8:42 AM, in message 4a8c0f3a.5080...@pocock.com.au,
Daniel
Pocock dan...@pocock.com.au wrote:
Bernard Li wrote:
On Tue, Aug 18, 2009 at 8:22 AM, Brad Nicholesbnicho...@novell.com wrote:
I'm not sure that there has been
Jesse Becker wrote:
I think that $rrd_options might be defined in the wrong spot?
I'm getting lots of Undefined variable: rrd_options in functions.php error
messages in trunk. It is used in functions.php in two places, as of r2049.
Digging a bit, I see that $rrd_options is defined at the
Daniel Pocock wrote:
Jesse Becker wrote:
I think that $rrd_options might be defined in the wrong spot?
I'm getting lots of Undefined variable: rrd_options in functions.php error
messages in trunk. It is used in functions.php in two places, as of r2049.
Digging a bit, I see
If anyone is interested in testing the Ganglia build on the OpenCSW
build farm, it is now possible. This provides access to a range of
Solaris machines including version 8.
libconfuse is now packaged and pre-installed on the OpenCSW machines, so
all the dependencies for building Ganglia are
Jesse Becker wrote:
On Thu, Sep 10, 2009 at 13:28, Daniel Pocock dan...@pocock.com.au wrote:
The reason I didn't put $rrd_options in conf.php is because it's value
is meant to be derived from other variables, in other words, the
administrator should not change $rrd_options itself
As discussed a few weeks back, I'm volunteering to manage the 3.1.3 release.
Most of the changes were made a few weeks ago now, and I've been running
some of these patches on several platforms for some time, so I don't
think we need to allow a lot of time for additional testing. What I'd
BTW, I would be busy starting early Friday afternoon, so if possible,
could you tag 3.1.3 early Friday? BTW, what timezone are we talking
about ;-)
Ok, I will aim for some time between 10:00 and 14:00 British Summer Time
(BST)
Bernard Li wrote:
Hi Daniel:
On Wed, Sep 16, 2009 at 10:56 AM, Daniel Pocock dan...@pocock.com.au wrote:
Ok, I will aim for some time between 10:00 and 14:00 British Summer Time
(BST)
As soon as 3.1.3 is tagged, I'll go ahead and generate the tarball and
(S)RPMs and will place
Bernard Li wrote:
On Thu, Sep 17, 2009 at 3:47 PM, Bernard Li bern...@vanhpc.org wrote:
changelog: typically the release manager goes through the check-ins
and highlights important bugfixes/new features to be included in the
email. When a GA is ready, then I will paste the same details
Jesse Becker wrote:
On Fri, Sep 18, 2009 at 08:58, daniel.poc...@barclayscapital.com wrote:
Fair enough. I didn't realize it was a recent addition, and
given the long %changelog, was surprised to see it still at
1. I'll add a note in the specfile about updating it, and
bump the
Brad Nicholes wrote:
Up and running on my SLES-10.2 test machine. Everything is looking good so
far.
I've also rebuilt the OpenCSW testing packages using the 3.1.3 code:
http://mirror.opencsw.org/testing.html
I notice that the library name/version is hardcoded in the spec file,
e.g. libganglia-3_1_0
Is it intended that the library name should be the same for all 3.1.*?
--
Come build with us! The BlackBerryreg; Developer
I've been testing 3.1.3 on the machine build8st in the OpenCSW build
farm (Solaris 8 sparc machine)
It fails on the third ioctl from libmetrics/get_ifi_info.c
I don't believe this is a regression with 3.1.3 as get_ifi_info.c hasn't
changed. More likely, it is due to the fact that it hasn't
Bernard Li wrote:
Hi Brad:
On Thu, Oct 1, 2009 at 3:57 PM, Brad Nicholes bnicho...@novell.com wrote:
If this is just a simple fix, then I would vote for scraping 3.1.3, rolling
3.1.4 with the fix and resetting the test period. The other option, since
this isn't a regression, would be
Bernard Li wrote:
Hi Daniel:
On Sun, Oct 11, 2009 at 9:36 PM, Daniel Pocock dan...@pocock.com.au wrote:
Another issue I found: the gmond binary built on RHEL3 can't run properly
because APR_POLLSET_THREADSAFE is not supported on that platform. The fix
for this is relatively trivial, we
Carlo Marcelo Arenas Belon wrote:
On Mon, Oct 26, 2009 at 04:51:33PM -0700, Bernard Li wrote:
Ganglia 3.1.4 is ready for testing at:
http://ganglia.info/testing/
DragonFlyBSD fails to build (tested with 2.4.0 32bit).
not a regression (a system header problem which also affects
In the wiki, it says `version numbers are cheap'
http://sourceforge.net/apps/trac/ganglia/wiki/how_project_works
However, the convention of naming the releases puts a little bit more
emphasis on the significance of each tag and release. Skipping a
release (e.g. 3.1.3) certainly doesn't give
Bernard Li wrote:
Hi Paul:
Have you tried these OpenCSW packages:
http://mirror.opencsw.org/testing.html
Or is there a specific reason why you would want to build Ganglia yourself?
Also see:
scripts/build-solaris.sh (I added this recently on 3.1)
and
Bernard Li wrote:
Dear all:
Please see this discussion we had last year:
http://www.mail-archive.com/ganglia-developers@lists.sourceforge.net/msg04697.html
Ok, summarising that discussion:
- the version number is the official unique identifier of the release
- release name is a
Bernard Li wrote:
Well, sounds like we have enough +1s, so please make it happen.
I'm happy to do this as part of 3.1.5 (which I will volunteer to be
release manager for)
That means there is still time for any final comments on the issue, as
3.1.5 will probably be late November or
Carlo Marcelo Arenas Belon wrote:
On Thu, Oct 29, 2009 at 04:44:59PM +, Paul Sobey wrote:
I note from the Makefile Daniel posted:
# Depends: some issues exist getting the Python support working on
Solaris,
# Ganglia's configure.in needs to be further enhanced for this to work
Carlo Marcelo Arenas Belon wrote:
On Thu, Oct 29, 2009 at 08:42:05PM +, Daniel Pocock wrote:
Carlo Marcelo Arenas Belon wrote:
On Thu, Oct 29, 2009 at 04:44:59PM +, Paul Sobey wrote:
I note from the Makefile Daniel posted:
# Depends: some issues exist getting
Bernard Li wrote:
Hi Carlo:
On Thu, Oct 29, 2009 at 4:47 PM, Carlo Marcelo Arenas Belon
care...@sajinet.com.pe wrote:
Ideally, which platform is used to bootstrap shouldn't be relevant though
and IMHO we should be instead aiming to the latest versions of the autotools
(either
Bernard Li wrote:
Hi Paul:
On Mon, Nov 2, 2009 at 12:57 AM, Paul Sobey bud...@the-annexe.net wrote:
Quick note to let you know 3.1.4 beta builds fine without Python support
using gcc 4.4.1/Solaris ld (and the -std=gnu99 CFLAG). I'll continue to
monitor the users list for hints as to
Jesse Becker wrote:
On Tue, Nov 3, 2009 at 03:26, Carlo Marcelo Arenas Belon
care...@sajinet.com.pe wrote:
I notice it can do some handy tricks, like generating version numbers that
reflect the tag you are building in
it can also do some more interesting tricks, like
Brad Nicholes wrote:
On 11/10/2009 at 4:11 AM, in message
d2d9beb20911100311k1a9ae67o11b0d47eaff69...@mail.gmail.com, Himanshu Sharma
himan...@berkeley.edu wrote:
Hello all,
We were looking to store Ganglia data in MySql rather than just an
RRD. There was a discussion earlier
Brad Nicholes wrote:
On 11/10/2009 at 9:30 AM, in message 4af9952a.9070...@pocock.com.au,
Daniel
Pocock dan...@pocock.com.au wrote:
Brad Nicholes wrote:
On 11/10/2009 at 4:11 AM, in message
d2d9beb20911100311k1a9ae67o11b0d47eaff69
Bernard Li wrote:
Hi Daniel:
On Tue, Nov 10, 2009 at 8:30 AM, Daniel Pocock dan...@pocock.com.au wrote:
Which gmetad is intended to be on the future roadmap?
For a large site, do you believe it is fair to say that the C
implementation is best for performance?
I think
How do people feel about making 3.1.4 GA?
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best,
As discussed previously on the list, I've adapted gmetad to use apr's
sleep functionality. For anyone using trunk, please run autoreconf
./configure to get the newest gmetad/Makefile
Changing the sleep code to randomize intervals using a percentage rather
than absolute value should be
Brad Nicholes wrote:
I've been running it on a very small set of machines. It all looks good to
me.
No complaints from anyone... is that sufficient to go live? I'm not
sure if I have the access level to put the release on the SF site though.
:
On 11/20/2009 at 8:46 AM, in message 4b06b9d6.5080...@pocock.com.au,
Daniel
Pocock dan...@pocock.com.au wrote:
Brad Nicholes wrote:
On 11/20/2009 at 8:07 AM, in message 4b06b0af.1050...@pocock.com.au,
Daniel
Pocock dan...@pocock.com.au wrote
Vladimir Vuksan wrote:
Little gripe about 3.1.4 (and looks like 3.1.3). Apparently SYSCONFDIR
has been changed to
/etc
instead of
/etc/ganglia
in the Makefile. This breaks the RPMS since the SPEC files are
configured to use /etc/ganglia and gmond will fail at startup :-(.
Perhaps
Bernard Li wrote:
Hi Vladimir:
I tested the 3.1.4 RPMs I've built and did not observe the issue you
encountered. Can you please outline how you built the RPMs?
Daniel -- if it's okay with you, I'd like to hold off on releasing
3.1.4 until we get this issue clarified with Vladimir.
Vladimir Vuksan wrote:
I used ganglia.spec file I used with 3.1.2 and just changed the
version. I determined that the difference is this
%configure --with-gmetad
---
%configure --with-gmetad --enable-status --sysconfdir=%{conf_dir}
That is why I see the problem. If you run configure
Which tarball should I be posting?
http://www.mail-archive.com/ganglia-developers@lists.sourceforge.net/msg05281.html
The official version - any changes from the unofficial tarball (using a
different autotools version to bootstrap) should be aimed at the next
release and captured in the
Hi all,
There has been some discussion about which version of autotools to use
for bootstrapping
3.1.2 was bootstrapped with automake 1.9.6 and autoconf 2.59
3.1.4 was bootstrapped with automake 1.9.2 and autoconf 2.59
Some people test an alternative tarball bootstrapped with 1.10.1 and
One problem I've been wondering about recently is the scalability of
gmetad/rrdtool.
Various events could impact the gmetad server load:
- adding more clusters - in this case, the admin can easily decide to
add the new cluster on a new gmetad server if the existing server is
overloaded
-
For those following trunk, you may need to bootstrap again, and make
sure you have pcre available.
I've linked gmond with libpcre so that it can dynamically match the
metric names
E.g., for the multicpu module, this is the only metric definition that
needs to be given to enable all metrics
Carlo Marcelo Arenas Belon wrote:
On Sun, Nov 29, 2009 at 10:57:01AM +, Carlo Marcelo Arenas Belon wrote:
On Tue, Nov 24, 2009 at 06:03:51PM -0800, Bernard Li wrote:
Please help us test on as many OS/archs as possible, as this would go
GA quite immediately ;-)
FreeBSD
Carlo Marcelo Arenas Belon wrote:
On Mon, Nov 30, 2009 at 08:12:34AM +, Daniel Pocock wrote:
Carlo Marcelo Arenas Belon wrote:
On Sun, Nov 29, 2009 at 10:57:01AM +, Carlo Marcelo Arenas Belon wrote:
On Tue, Nov 24, 2009 at 06:03:51PM -0800, Bernard Li wrote
At least a revert would be needed for 3.1 as this accounts for a regression
but haven't done so either waiting for you to first revert it on trunk and
then decide on how to proceed from there depending on how critical this
feature was for the release.
I agree that it is a
Carlo Marcelo Arenas Belon wrote:
On Wed, Dec 02, 2009 at 01:57:44AM +, Carlo Marcelo Arenas Belon wrote:
On Tue, Dec 01, 2009 at 10:20:32PM +, Daniel Pocock wrote:
- Can you easily re-compile APR with a different poll implementation? I
think you can change it from
fork() doesn't work because the kqueue filehandle is not inherited; using
rfork() instead doesn't either because all filehandles are closed by doing
exit(0) in the parent and so fails in the same way that changing
apr_proc_detach() does when changed to use rfork() instead.
I'm not a BSD
Gladish, Jacob wrote:
-Original Message-
From: Daniel Pocock [mailto:dan...@pocock.com.au]
Sent: Wednesday, December 02, 2009 6:49 AM
To: Carlo Marcelo Arenas Belon
Cc: ganglia-developers@lists.sourceforge.net; Ganglia
Subject: Re: [Ganglia-developers] [Ganglia-general] Ganglia
Brad Nicholes wrote:
On 12/2/2009 at 7:21 AM, in message 4b1677e4.8000...@pocock.com.au,
Daniel
Pocock dan...@pocock.com.au wrote:
I would like gmond to return a non-zero return code if it fails to
initialise, e.g. if it is unable to bind or if it is unable to resolve
Carlo Marcelo Arenas Belon wrote:
On Wed, Nov 25, 2009 at 11:00:21AM +, Daniel Pocock wrote:
a) is it preferred that we release 3.1.4 or that we release 3.1.5, or a
third option, roll a 3.1.6 tarball using the same environment where
3.1.2 was bootstrapped?
3.1.2 had
it replaces apr_proc_detach with an inline implementation of it on plain
POSIX and that should be most likely as portable (at least for the platforms
we care of) and doesn't intentionally include any error checking to make it
How about Cygwin and mingw? I'm not sure if the use of pipe(),
Spike Spiegel wrote:
On Wed, Nov 25, 2009 at 4:20 PM, Daniel Pocock dan...@pocock.com.au wrote:
One problem I've been wondering about recently is the scalability of
gmetad/rrdtool.
[cut]
In a particularly large organisation, moving around the RRD files as
clusters grow could
Brad Nicholes wrote:
On 12/11/2009 at 6:21 AM, in message 4b224750.2090...@pocock.com.au,
Daniel
Pocock dan...@pocock.com.au wrote:
it replaces apr_proc_detach with an inline implementation of it on plain
POSIX and that should be most likely as portable (at least
Carlo Marcelo Arenas Belon wrote:
On Fri, Dec 11, 2009 at 01:31:22PM -0600, Brooks Davis wrote:
On Fri, Dec 11, 2009 at 04:56:51PM +, Carlo Marcelo Arenas Belon wrote:
I presume the reason why you haven't seen this show up in the APR list, is
because it makes probably more sense
Vladimir Vuksan wrote:
I think you guys are complicating much :-). Can't you simply have
multiple gmetads in different sites poll a single gmond. That way if
one gmetad fails data is still available and updated on the other
gmetads. That is what we used to do.
That is a good solution under
Carlo Marcelo Arenas Belon wrote:
On Sun, Dec 13, 2009 at 10:49:00AM +, Daniel Pocock wrote:
Carlo Marcelo Arenas Belon wrote:
On Fri, Dec 11, 2009 at 01:31:22PM -0600, Brooks Davis wrote:
On Fri, Dec 11, 2009 at 04:56:51PM +, Carlo Marcelo Arenas Belon wrote
Rick Cobb wrote:
Changed subjects because this part of the discussion is important
enough to have its own thread
On Dec 20, 2009, at 8:55 AM, Jesse Becker wrote:
On Sun, Dec 20, 2009 at 11:02, Spike Spiegel fsm...@gmail.com
mailto:fsm...@gmail.com wrote:
...
I think there's a middle
Vladimir Vuksan wrote:
On Mon, 21 Dec 2009, Spike Spiegel wrote:
a. Get all the rrds (rsync) from gmetad2 before you restart gmetad1
which unless you have small amount or data or fast network between the
two nodes won't complete before the next write is initiated, meaning
they won't be
Jesse Becker wrote:
On Sat, Nov 28, 2009 at 08:42, Daniel Pocock dan...@pocock.com.au wrote:
For those following trunk, you may need to bootstrap again, and make
sure you have pcre available.
I've linked gmond with libpcre so that it can dynamically match the
metric names
E.g
Carlo Marcelo Arenas Belon wrote:
On Sun, Dec 06, 2009 at 09:28:04AM +, Daniel Pocock wrote:
Carlo Marcelo Arenas Belon wrote:
On Wed, Nov 25, 2009 at 11:00:21AM +, Daniel Pocock wrote:
b) should the choice of bootstrap environment be locked for all
3.1.X
Carlo Marcelo Arenas Belon wrote:
On Fri, Dec 18, 2009 at 04:18:16PM +, Daniel Pocock wrote:
Carlo Marcelo Arenas Belon wrote:
On Sun, Dec 13, 2009 at 10:49:00AM +, Daniel Pocock wrote:
I could accept Brooks' solution, because it means gmond would only
fail
Carlo Marcelo Arenas Belon wrote:
On Mon, Dec 28, 2009 at 08:47:35PM +, Daniel Pocock wrote:
Jesse Becker wrote:
On Sat, Nov 28, 2009 at 08:42, Daniel Pocock dan...@pocock.com.au wrote:
For those following trunk, you may need to bootstrap again, and make
sure you
Carlo Marcelo Arenas Belon wrote:
On Mon, Dec 28, 2009 at 10:51:51PM +, Daniel Pocock wrote:
Carlo Marcelo Arenas Belon wrote:
On Sun, Dec 06, 2009 at 09:28:04AM +, Daniel Pocock wrote:
Carlo Marcelo Arenas Belon wrote:
On Wed, Nov 25, 2009 at 11
after adding some basic documentation to trunk in r2122 and using them had
found that the interface should be better improved before it gets released
by either :
* remove bind_hostname and overload that functionality on bind by defining
a magic value which means (resolve default hostname)
Carlo Marcelo Arenas Belon wrote:
On Tue, Jan 05, 2010 at 02:42:28PM +, Daniel Pocock wrote:
Carlo Marcelo Arenas Belon wrote:
On Mon, Dec 28, 2009 at 10:51:51PM +, Daniel Pocock wrote:
Carlo Marcelo Arenas Belon wrote:
On Sun, Dec 06, 2009 at 09:28:04AM
I've backported the rrdcached support to monitor-core-3.1 branch
Any feedback is welcome
- it is an optional feature, disabled by default
- I've been running it successfully
- it has been in trunk for a while
--
This
I've been contemplating the multicpu module, which currently only works
on Linux and Cygwin.
Carlo has indicated that promoting it's use (as a consequence of the
PCRE patch) may not be ideal for two reasons:
a) bugs on the supported platforms (Linux and Cygwin)
b) not functional on other
I've just looked at r2133.
I notice that there is a call to load_metric_modules() within the first
conditional block (args_info.metrics_flag).
Therefore, to solve the problem addressed by r2133, I believe one of the
following alternatives is needed:
a) put a call to load_metric_modules()
I've just done some backports for 3.1.6 (see log below), there may be a
couple of others to come too
- are there any more backports that people would like?
- it's probably time for people to start testing the monitor-core-3.1
branch with the view that we will tag 3.1.6 in the next 1-2 weeks
Hi all,
3.1.6 will be tagged during January
A number of different bug fixes and feature enhancements have been
backported. There is always a risk that new regressions have been
created. If necessary, we can still make further enhancements, or
remove any backport that is causing trouble.
the lead on this release. Appreciated.
-Matt
On Tue, Oct 27, 2009 at 1:13 PM, Daniel Pocock dan...@pocock.com.au
mailto:dan...@pocock.com.au wrote:
Bernard Li wrote:
Well, sounds like we have enough +1s, so please make it happen.
I'm happy to do
Before 3.1.3, /etc/ganglia was hardcoded into various places in the code
As of 3.1.3, the code refers to $sysconfdir
If configure is called without specifying --prefix or --sysconfdir, then
the default value is /usr/etc/ganglia
configure.in could be tweaked to check if the user has
Daniel Pocock wrote:
Before 3.1.3, /etc/ganglia was hardcoded into various places in the code
As of 3.1.3, the code refers to $sysconfdir
If configure is called without specifying --prefix or --sysconfdir, then
the default value is /usr/etc/ganglia
configure.in could be tweaked to check
I've sought some feedback on the automake list about how to generate
modpython.conf and others that have to include @sysconfdir@
A few people have contributed suggestions here:
http://lists.gnu.org/archive/html/automake/2010-01/msg00021.html
I'll be integrating some of this over the next
Daniel Pocock wrote:
I've sought some feedback on the automake list about how to generate
modpython.conf and others that have to include @sysconfdir@
A few people have contributed suggestions here:
http://lists.gnu.org/archive/html/automake/2010-01/msg00021.html
I'll be integrating some
I've created branches/monitor-core-3.1-aix and applied the following:
BUG226: detect virtual IO server
BUG227: I've modified the patch to try and selectively set the linker
flags for AIX and for fabsf on AIX 5.2
I'd also like to test the effect the new autotools have on AIX
Therefore, I've
broken libraries where you run into
problems only at runtime
Hope that helps
Regards,
Michael
On 01/15/2010 12:34 PM, Daniel Pocock wrote:
I've created branches/monitor-core-3.1-aix and applied the following:
BUG226: detect virtual IO server
BUG227: I've modified the patch
I had already applied that on the branch, but to make the code
portable between AIX and other platforms, I did this by setting
EXPORT_SYMBOLS_DYNAMIC in configure.in and using it's value in
gmond/Makefile.am
Can you please look at whether EXPORT_SYMBOLS_DYNAMIC is being used
properly?
Hi all,
I'm not too sure why we have a second configure script for the
libmetrics tree - could anybody give me some background information
about this?
Is libmetrics used anywhere else, or is it intended to be?
Regards,
Daniel
Steven A. DuChene wrote:
I see in the ganglia spec file and the configure script
that the compilation of ganglia 3.1.4 depends on apr-1
It is definitely used by both gmond and gmetad
Older versions of apr (e.g. the one which ships with RHEL4) don't work
for gmond.
I am trying to add a
1 - 100 of 292 matches
Mail list logo
