For what it's worth, I wrote a fairly grotesque Nagios external command
formatter for the Ganglia Python module. It runs every couple of
minutes, parses the gmetad output and jams the result into my Nagios
external command file. It also determines metric warning and critical
thresholds, which
ne support working under 3.0.x.
I do remember that getting that much of it to run was a big headache...
Anyway, good luck!
steven wagner wrote:
Hi, I'm still here! (lurking...)
I no longer have any Tru64 systems to maintain that port (such as it
was), so I can't really address any
Hi, I'm still here! (lurking...)
I no longer have any Tru64 systems to maintain that port (such as it
was), so I can't really address any current build issues.
But I can verify that, yes, it did work once. :)
Christoph Mertins wrote:
Hello,
I have some Tru64 boxes here. I can't get rid of
Did anyone fix the RRDtool referral URL in the documentation and in
configure yet? I just noticed that. It's supposed to be rrdtool.org,
not rrdtool.com ...
Believe it or not, I still have IRIX boxes to deal with (a few lowly
O2s), so I can toss this snapshot on 'em this week.
BTW, rehi ev
I haven't had to build it lately, but back when I was working on the
Solaris metrics and pirate dinosaurs ruled the Earth, I had nothing but
trouble with the Solaris compiler. I switched to gcc, had a much easier
time, and didn't look back.
Hopefully this has changed by now, but then again ma
On my 7.2 box with 2.96 and 3.3.2 compilers, the configure and build appear to
work OK - running the resulting gmond yields:
[EMAIL PROTECTED] gmond]$ ./gmond
Couldn't create socket
The test daemon then exits to shell.
On my SuSE 9.1 system (which is somewhat mroe vanilla), it configures, buil
Preston Smith wrote:
On Mon, 2004-06-21 at 16:21, steven wagner wrote:
Matt Massie wrote:
do you mean that if you turn on debugging that gmond doesn't work
anymore?
Nope, the opposite:
If I turn *OFF* debugging, gmond doesn't work anymore.
With debugging on, gmond works as expe
Matt Massie wrote:
Update: Works fine on a RH9-derivative.
Name: glibcRelocations: (not relocateable)
Version : 2.3.2 Vendor: Red Hat, Inc.
Release : 27.9.7Build Date: Wed Nov 12 16:19:15 2003
Install D
Matt Massie wrote:
do you mean that if you turn on debugging that gmond doesn't work
anymore?
Nope, the opposite:
If I turn *OFF* debugging, gmond doesn't work anymore.
With debugging on, gmond works as expected. But the lack of daemonization is
a bit of a drag.
When built from *this* 2.
A few other things exploded so I've only just had the chance to check this
out. Info:
I'm not using a config file at this time. This is a Redhat 7.1 uniprocessor
P4 but I get the same results on a dual-proc Opteron running the same
bastardized RH7.1-derivative.
When built from the 2.5.6 ta
Matt Massie wrote:
i also heard reports from steve wagner about segfaults when you don't run
gmond in debug mode.
I never specifically receive segfaults and the monitoring core seems to run:
ps -aef | grep gmond
nobody 15920 1 0 Jun04 ?00:00:00 ./gmond
nobody 15921 15920 0
Rehi gang!
Tossed the latest version of 2.6.0's monitoring core up on one of our shiny
new dual Opterons and it apparently only responds if debug_level is set
nonzero. Doesn't seem to matter whether it's 1 or 10 or 90.
Doesn't seem to matter whether there's a config file present, either.
Hmm, I must have been on vacation or something.
Regardless, I don't have this code.
And for the record, I never said I was happy about having to run gmond
as root instead of nobody. :)
Adeyemi Adesanya wrote:
Hi Christopher.
I have not received a response from Steven Wagner so I will
I feel compelled to respond since I was probably the last person to
attempt to document metrics...
Someone has just won themselves the grand prize, a self-guided tour of
the gmond/machines/$platform_name.c file!
In this file you'll find out exactly where and how your version of
Ganglia compu
matt massie wrote:
steve-
the RSS idea is right on track. i didn't make this clear in my email
before. you can easily get XML from gmetad to use for a PHP web frontend.
say you visited the demo site and browse the contents to find exactly the
data set that you wanted .. and the URL was (fo
I used to have problems similar to this one. It turned out that a
malformed gmetric value was "poisoning" gmetad. I suggest you check the
XML output of the data source as soon as gmetad starts reporting this
error, and see what's going on at that line in the XML...
(sounds like fun, doesn't
matt massie wrote:
Today, Jason A. Smith wrote forth saying...
From: Jason A. Smith <[EMAIL PROTECTED]>
To: matt massie <[EMAIL PROTECTED]>
Cc: Ganglia Developers ,
[EMAIL PROTECTED]
Date: Wed, 03 Sep 2003 15:37:34 -0400
Subject: Re: [Ganglia-developers] g3 update
The only question I have
matt massie wrote:
Today, steven wagner wrote forth saying...
Gexec hasn't really had a lot of development time thrown at it lately.
the truth is that there is development happening on gexec but it is
scattered. i know of a number of groups that have incorporated it into
their l
Gexec hasn't really had a lot of development time thrown at it lately.
Unless I missed a couple e-mails on this list. :) Last I heard it was
in an unmaintained but compatible state, with some moldy documentation.
Hey, how's Gexec going to fit in to g3? Should we be looking at that
more clos
matt massie wrote:
is anyone in the group a subscriber of linux magazine? i just got a
voicemail from a friend who told me ganglia made the front cover. i
thought it was a joke but i just checked their web site and it's true.
http://www.linux-mag.com/
if you check on the left-hand side..
Hmmm ...
/proc/cpuinfo on my desktop (2.4.3 kernel ... don't start with me!) :
processor : 0
vendor_id : GenuineIntel
cpu family : 15
model : 2
model name : Intel(R) Pentium(R) 4 CPU 2.20GHz
stepping: 4
cpu MHz : 2193.403
cache size : 512 KB
fd
Not all metrics are supported on all platforms, for a variety of reasons
(which typically fall into two categories: "We haven't figured out
how to measure that," or, "We don't have the time to implement that.").
You think Solaris is bad - look at Tru64. :)
Due to the way Ganglia communicat
irix.c still had a lot of stub code in it when I started working on it,
but I can't claim original authorship...
Martin Knoblauch wrote:
Hi,
please review and take the appended patch against irix.c and hpux.c.
hpux.c:
---
Just some small cosmetics fixes in error messages
irix.c:
--
Martin Knoblauch wrote:
On Monday 05 May 2003 19:31, Federico Sacerdoti wrote:
This is one of those hard-to-anticipate bugs which occur from
unintended side effects to the system. To fix it, I believe we need to
use the true localtime when updating rrds for which we are not the
"authority" o
-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of
steven wagner
Sent: Wednesday, April 30, 2003 5:46 PM
To: Federico Sacerdoti
Cc: Ganglia
Subject: Re: [Ganglia-developers] Announce: subtree-capable gmetad
Oooh!
I haven't played with this yet (I'm examining the diff right n
Oooh!
I haven't played with this yet (I'm examining the diff right now) ...
but I really hope a host-only cluster view is in there.
In other words:
The summary code looks like it summarizes all numeric metrics for the
cluster but doesn't display the individual hosts...
I
matt massie wrote:
i just uploaded another snapshot of ganglia
http://matt-massie.com/g3/ganglia-3.0.0.tar.gz
i've been working on polishing the xml before i start work on the
s-expressions side of things (since sexpressions will just be condensed
versions of the xml).
the latest snapsh
matt massie wrote:
Today, Steven Wagner wrote forth saying...
ftp://ftp.isi.edu/in-notes/rfc2616.txt
has the RFC 2616 for the HTTP 1.1 protocol (we'll have to use 1.1 since
1.0 doesn't understand persistent client connections.. and why not use
the latest version...).
We'
matt massie wrote:
ftp://ftp.isi.edu/in-notes/rfc2616.txt
has the RFC 2616 for the HTTP 1.1 protocol (we'll have to use 1.1 since
1.0 doesn't understand persistent client connections.. and why not use
the latest version...).
We'll also have to make sure Ganglia is RFC-3514-compliant, as well
matt massie wrote:
Today, Steven Wagner wrote forth saying...
Or we can convert the string to:
ganglia://meta.rocksclusters.org/san%20diego%20grid/sdsc%20rocks%20grid/meteor?compute-0-2
The question-mark just occurred to me. :)
i like the question mark as a delimiter because it looks
the format should also allow collection of summary data
ganglia://meta.rocksclusters.org/san diego grid///cpu/number
would point to the number of cpus on the entire san diego grid (since it
has an empty host tag). since the host tag is empty the "browser" would
"know" that the data was not av
Federico Sacerdoti wrote:
On Monday, March 31, 2003, at 10:42 AM, Steven Wagner wrote:
for example. :) but we'd need to delimit the DNS portion somehow
because say...
ORG:RocksClusters:Meta:San Diego Grid:SDSC Rocks
Grid:Meteor::computer-0-2
doesn't work... only part of
matt massie wrote:
Today, Federico Sacerdoti wrote forth saying...
I dont understand. Floats and doubles often will be generated in binary.
For example a detailed running time from MPI_Wtime() or a GPS
coordinate. No matter how you slice it, storing it in ascii means a
conversion. That convers
I can see I'm going to have to drop the microphone mathematics.
matt massie wrote:
so i'm pretty certain g3 will be a pure xml beast. no more xdr messages
on the wire. here's my thinking on this...in no necessary order..
I'm going to shock you by saying I don't like this. I know, you're ask
Preston Smith wrote:
On Thu, Mar 27, 2003 at 01:31:36AM -0500, Lester Vecsey ([EMAIL PROTECTED])
wrote:
I compiled gmond on FreeBSD 4.4-RELEASE and I'm running it with a non-root
account.. /dev/mem on the machine isn't accessible from this account, and so
theres a segfault on kvm_open when I r
An amazing variety of things are keyed off an /etc/hosts entry in Solaris
(including network interface configuration, if memory serves). This man
speaks the truth.
However, I put it to you, world, that if this has only popped up on Sun
boxes, a better solution might be to quietly change solar
... real logging facility.
You know.
Specified in the config file.
Defaults to "/var/log/gmetad".
Spews timestamped error-and-above-level messages.
Might help me figure out why my gmetad stopped working about 30 minutes
ago, or why it comes right up when I restart it.
Yet running it in ful
Jason A. Smith wrote:
I do agree with you about making sure that the second gmetad has a
polling interval set to be the same or greater than the interval in the
gmetad that it is getting data from. What is a safe value to use here
anyway? This does help, but not eliminate the problem. It looks
matt massie wrote:
john-
what do you see when you run
% gstat -a
you might want to alias gstat to "gstat -a". right now, gstat only shows
hosts running "gexec" unless you specify the -a flag.
that behavior is very likely to change in the future. sorry for the
hassle.
How odd - he's n
Jason A. Smith wrote:
Which cause the now famous gaps in the rrd graphs when looking at the
hour resolution. The 2.5.2 version of gmetad does not have a problem
getting data from gmetad with the grid tag removed, but 2.5.3 does so I
can only assume it must be related to the new timestamp patch.
matt massie wrote:
steve-
i've been thinking very hard about this lately. ganglia was originally
just a system for monitoring a single cluster. the xml size wasn't a
problem because you where collecting it locally and it wasn't being
aggregated across cluster. gmetad was my first stab at b
Has anyone given any thought (or ink) to this? In other words, a change in
gmetad's behavior, possibly governed by a configuration directive or
running on a different port, that allows users to run queries against its
database?
I suggest a well-understood query language (SQL or HTTP spring to
matt massie wrote:
steve-
great patch! good contribution (although Gap, Inc. might force you to
change the name :P)
do you have any idea how the RRDs got corrupted?
Leading theory on that is that the cron job I was using to copy over RRDs
to a backup location wasn't working correctly (pl
This patch was made against 2.5.2 - I haven't tested it on the latest CVS
version.
What you get:
* gmetad starts passing a timestamp value down to the individual RRD
updating functions.
* If a timestamp isn't provided, it generates one using your platform's
POSIX-compliant time() function.
So, after trimming out a few data_source lines from gmetad.conf, I cranked
up my new 2.5.2-modified version again to see how long it lasted.
And the answer is ... about 45 minutes. (42, actually ... now you know
what the question is!)
I noticed similar stalling with 2.5.0, so I'm not sold on
matt massie wrote:
steve-
your idea is right on. i'm actually embarrassed that i didn't think of
that before.
man... if you only have 128 node cluster w/30 standard metrics.. that
means that every 15 seconds you are making 3840 gettimeofday() system
calls. ouch!
there is also another
So lately, as the size of one of my clusters' RRD directory baloons past
the third-of-a-gigabyte mark, I've been noticing a dramatic increase in
data gaps in some of the graps.
I decided to put my money ... er, *development time* where my mouth ... er,
*whiny developer ranting* is and modified
I don't have my notes on the specifics anymore, but the stock prefab gcc is
almost certainly NOT going to build 64-bit binaries.
What you end up having to do is ... download your favorite gcc core
version, and then configure it to build sparcv9 binaries (64-bit sparc).
Check the gcc documenta
Jim Rowan wrote:
...
When you do eventually get it built, be aware that some of the metrics
that it reports aren't actually collected. You get a flat line. :(
Hey everybody! Jim just volunteered to write more Solaris metrics!!!
:P
Actually, I have some (ugly) code that looks like it wo
I'm not letting Matt take a bullet with my name on it! :)
What support there is in Ganglia for Solaris (sparc, that is) is mostly my
fault. All of my development used a 64-bit gcc 3.0.x compiler.
The monitoring core is smart enough to realize, once it's executed, that
it's using a 32-bit ker
[EMAIL PROTECTED] wrote:
Dear Sir:
I am a graduate student in Louisiana Tech University currently doing research
on Ganglia. I am trying to find out how gangia monitor core works to get the
hardware information from the node. I searched the web but can not find
information on this field.
libmysqld is out, allowing developers to embed a MySQL server in just about
anything.
Just thought I'd mention that. :)
I'd personally like to see the ability to get subsets of gmetad's stored
dataset. Remember, I'm at 8 seconds per fricken' page load over here. :)
Now the question becomes, where does the authentication take place? In the
front-end code, I should think. Unless there's a plan to write a whole
matt massie wrote:
Today, Steven Wagner wrote forth saying...
So, looking at this here example plugin (and writing one of my own, the
aforementioned universal uname plugin), I'm wondering if it's part of The
Plan for the plugin to determine when to publish its metrics. I no
So, looking at this here example plugin (and writing one of my own, the
aforementioned universal uname plugin), I'm wondering if it's part of The
Plan for the plugin to determine when to publish its metrics. I notice
that g3_job_t has a reference to a collect function *and* a publish
function,
Joe Griffin wrote:
Hi All,
Is there any similar information on gmetric?
I found a script I would like to use in number 16 of:
http://ganglia.sourceforge.net/gmetric/
However, I cannot get gmetric to print any output.
For example, I tried:
/usr/bin/gmetric --name "Resource_Usage_Rank 2" --valu
matt massie wrote:
steve-
you can see that the only metadata i've put in right now is plugin name,
author and version (see test-plugin.c ganglia_main()). i welcome any
ideas of more metadata that we need.
right now, i envision that we will have a service plugin directory (say
/var/lib/gan
Leif Nixon wrote:
Steven Wagner <[EMAIL PROTECTED]> writes:
First, the monitoring core RPM (at least on some mirrors ... ?)
requires librrd.
Ehm, I'm sure I'm missing something here, but in 2.5.1 the monitoring
core was split into two RPM:s, ganglia-monitor-core-gmetad and
So while I'm tooling around CVS, I'm reading Matt's latest g3 examples and
I start to think about plugins.
How is this going to work?
Will we have a baseline plugin for each platform (irix_baseline,
solaris_baseline), or will that be compiled-in in some form?
A version/compiled-on timestamp?
Finally, the Linux cluster's up to 2.5.1. Out of the stone age, into the
bronze age! (My scientists are now researching Mathematics...)
In the process of upgrading, we noticed a few things.
First, the monitoring core RPM (at least on some mirrors ... ?) requires
librrd. I'm not sure if the
Federico Sacerdoti wrote:
Since Matt is going to be indisposed for a while due to his new baby, I
will take this one.
:O!!!
Dang, more people I need to send shirts to this month. :P
We are definately planning to implement this idea, and I'm glad you see
the need for it. Matt's idea, which
IMO, if you are *really* super-concerned with data integrity for some sort
of alert system, bolting it onto gmetad doesn't seem like the best
solution. For starters, gmetad's XML snapshot is the only thing that's
current and easily-accessible (IMO). If you want more reliability, have it
query
It's also worth noting that there's no particular reason to avoid
developing other front-ends to Ganglia. If you'd rather build one your way
using a particular technology or library that better suits your needs, the
existing architecture makes it pretty easy for you to do so. Almost as if
it
Matt Massie wrote:
wade-
thanks for the great feedback. i've update CVS with your suggestions.
pkts_in/out and bytes_in/out now initialize variables to zero.
barrier_init return values are checked.
we run ganglia on dual and quad boxes all the time and have no
problems. i think that gangli
Wade Hampton wrote:
G'day,
I found some uninitialized data in gmond/machines/linux.c.
The functions pkts_in_func, pkts_out_func, bytes_out_func, and
bytes_in_func all do not properly initialize bytes_in, etc.
double bytes_in, bytes_out, , t =0;
Yay! It's MY code at fault! :)
Does mo
Federico Sacerdoti wrote:
On Monday, November 11, 2002, at 06:23 PM, Steven Wagner wrote:
[been waiting to spring that one :) ]
So it looks like gappy graphs are back on my large cluster data source
(which is actually now three or four hosts instead of just the one).
I haven't ch
[been waiting to spring that one :) ]
So it looks like gappy graphs are back on my large cluster data source
(which is actually now three or four hosts instead of just the one). I
haven't checked gmetad lately but does anyone know if it round-robins the
query hosts or is it just building a li
Lester Vecsey wrote:
I hacked in a force_foreground option into gmond 2.5.0, which essentially
just insures that the daemon_init() function never gets called.. regardless
of the debug level.
I use this with D.J. Bernsteins supervise tool, in his daemontools package
at http://cr.yp.to/daemontools
I noticed the Solaris 2.5.1 monitoring cores weren't running this morning,
but I haven't been able to reproduce it since then. And there were a
number of factors external to Ganglia going on over the last 36 hours which
may have contributed to it.
I'll scream bloody murder (or maybe "It's a c
:)
Matt Massie wrote:
steve-
just to clarify then.. the garbage collector is working on Tru64? are
you sure you didn't grep for "Cleanip" or "Clesnup" or "Cleamup"
before? :P
-matt
On Mon, 2002-11-04 at 14:36, Steven Wagner wrote:
Whoops, there we g
Whoops, there we go. The code *is* running, apparently. Although I
*SWEAR* it wasn't earlier... (otherwise a grep "Cleanup" would have
worked... ? )
Steven Wagner wrote:
Except the IRIX monitoring core is not configured as deaf *or* mute...
And the Solaris one, which *is
reate line somewhere outside
the "if (! gmond_config.deaf)" test, to see if it starts.
Hope this helps,
Federico
On Monday, November 4, 2002, at 11:10 AM, Steven Wagner wrote:
Using a "this-morning" CVS checkout (let's call it 9:45am PDT), I
started testing on my various
Using a "this-morning" CVS checkout (let's call it 9:45am PDT), I started
testing on my various platforms.
So far, Solaris is running like a top. However, on that box it's in
listen-only mode... I'll try it on one of the fileservers in a bit.
IRIX is running except for the cleanup thread. I
I've been really busy this week with other projects, so I haven't had a
chance to build and test the CVS snapshot on Tru64, Solaris and IRIX. If
anyone else wants to, knock yourselves out. :)
Depending on how Monday goes I'll try to upgrade it then.
We could always release it as beta...
matt
Steven A. DuChene wrote:
The released files on the ganglia sourceforge project page has the
gzipped tarball and i386.rpm but no source rpm. The tarball does
not include a spec file so I'm wondering where it is.
Also the i386.rpm includes php, jpg, template, and doc text files.
Why is this an i38
Steven Wagner wrote:
matt massie wrote:
steve-
to get gexec working with 2.5.0... you need to compile the
monitor-core with --enable-gexec. the reason gexec thinks there are
no hosts up is because no gmond is multicasting that it is available.
[insert Sims-style "Uh oh, you
matt massie wrote:
steve-
to get gexec working with 2.5.0... you need to compile the monitor-core
with --enable-gexec. the reason gexec thinks there are no hosts up is
because no gmond is multicasting that it is available.
[insert Sims-style "Uh oh, you just busted the dishwasher!" sound]
Just wondering if anyone'd been devoting any brain time to gexec lately.
The source tarball for 0.3.5 appears to be truncated, and 0.3.4 is using
the old "localtime - last-reported" method of determining a host's uptime.
I started investigating this because, when I pointed gexec at my
(admitte
matt massie wrote:
thanks for the bug report. the development team will take a look at the
changes to the 2.5.30 kernel and /proc/stat and be sure to update our
code.
We now bring you ... KERNEL PATCHES OF INTEREST!
From 2.5.18's changelog (forgive the formatting):
<[EMAIL PROTECTED]>
Personally, I think gexec could do with a major investment of quality time,
and it could use this kind of functionality. I like these ideas, but we
don't want to Microsoft Office the monitoring core.
The philosophy, in a nutshell, being that the monitoring core should
monitor, and the executi
Dave Ingram wrote:
On Fri, 11 Oct 2002, Steven Wagner wrote:
I have a G4 tower here on my desk which I *could* use for Jaguar
development. However, in my computing environment it doesn't make much
sense to pursue it aggressively.
A very fair response. :)
Unfortunately
Dave Ingram wrote:
Hello - our company is currently working with Apple to build
clusters around their new XServe dual-G4 boxes.
We have a cluster of 8 units, running OS X Jaguar (10.2).
After looking at Ganglia, I think this would be an invaluable tool
for working with this cluster.
Tingyu(Kevin) Zeng wrote:
> hi all,
> Now I am reading the source codes of gexec and gexecd, and met some
> problems. I can't find the explaination and implementation of some
> functions that establish the authentication in gexec.c and gexecd.c .
> For example, in gexec.c , i can not f
matt massie wrote:
http://freshmeat.net/articles/view/458/
just wanted to let you know that ganglia was mention in an article on
"Linux Clustering Software" on freshmeat.
the author had good things to say about ganglia.
-matt
That reminds me, did you ever post 2.5.0 to Freshmeat?
Ryan Sweet wrote:
On 25 Sep 2002, Jason A. Smith wrote:
It would probably be nice to have in the future. I am just thinking in
terms of configuration and administration of a large cluster. It is
things a little more difficult for software installation. Having it in
one central config file,
Ryan Sweet wrote:
On Tue, 24 Sep 2002, Federico Sacerdoti wrote:
Just by checking the number of disk interrupts we knew disk I/O was a
problem, not to mention the inconsistant-looking graphs. When we put the
At the moment disk I/O isn't the problem, though I see how it could be
once the re
Federico Sacerdoti wrote:
On Tuesday, September 24, 2002, at 10:49 AM, Steven Wagner wrote:
People have cited disk I/O as a bottleneck. I personally doubt this.
If it were true, you'd be seeing random gaps whenever RRD updates came
thick and fast (i.e. while all threads were updating
I was struggling with gapped output in the weeks leading up to 2.5.0's
release. I tried a staggering array of (mostly useless) tweaks.
Looks like your Apache rules won't let me view that URL (403), so I'm just
gonna guess.
People have cited disk I/O as a bottleneck. I personally doubt this.
Ryan Sweet wrote:
Thanks guys for the great 2.5.0 release!
the gmetad and gmond work great on all our linux systems.
However, I've got some trouble building for IRIX.
I had to add a dummy mtu_func to irix.c in order to get the monitor core
to build.
Yup, that's the fix. I guess that patch
According to the sourceforge project page (why am I checking the
sourceforge project page? .. no reason. :) ), we're in the 94.685th
percentile of activity. Or, to put it another way, the Ganglia project is
the 507th most active project on Sourceforge.
We are just behind the Linux NTF
matt massie wrote:
Today, Steven A. DuChene wrote forth saying...
So that doesn't really answer my question. How much has the code
changed in gmond since there was the command line options? I.E.
would it be fairly involved to add the old command line options
code (or perhaps just the "-iblah"
matt massie wrote:
we ARE going to release tomorrow.. come hell or high water or both. (i
guess technically they both can't happen at the same time because... well
nevermind)
OK, *someone* needs to re-read Dante's "Inferno."
And then watch The Abyss. ;)
Steven A. DuChene wrote:
So I looked around on the ganglia project pages on sourceforge but failed
to find any stuff labeled as 2.5.0 so I'm guessing this is a preliminary
rough draft of the planned announcement, correct?
Also I checked out of cvs the current ganglia, monitor-core, and monitor-d
proofreadin'...
matt massie wrote:
o the ganglia meta daemon (gmond) is now written in C and part of the
monitoring core distribution and:
i thought the ganglia meta daemon was "gmetad" :P
o ganglia has been ported to even more platforms: Linux (i386, ia64, sparc, alpha,
powerpc, m
State of the IRIX port:
* CPU percentage stuff hasn't improved despite my efforts. I fear there
may be a flaw in the way I'm summing counters for all the CPUs.
* Auto-detection of network interfaces apparently segfaults.
* Memory and load reporting appear to be running properly.
* CPU spe
Preston Smith wrote:
On Mon, Sep 16, 2002 at 06:08:21PM -0700, Federico Sacerdoti ([EMAIL
PROTECTED]) wrote:
Q. Why do we use libdnet?
A. Many things in unix are fairly similar across various OS flavors, whereas something as simple
as wanting to know "what are all the network interfaces on
So, I come back from a meeting and one of my cluster graphs is empty (the
meeting lasted about an hour). The other two continue to be updated.
I'm not logging anymore so I don't know exactly what happened, but the data
source is still active. I restarted gmetad and it's updating just fine
no
matt massie wrote:
Today, Steven Wagner wrote forth saying...
Slow down, there, Sparky. You still need to apply my rrd_helpers.c patch
to CVS. :)
sparky? hehe.
That's right, you don't watch Farscape...
please send me the patch and a short explanation of what it does.
matt massie wrote:
you are E*V*I*L!! the solaris (5.7 btw) box that i set up here is still
running strong after 3 days so i think we are ready for release today!
Slow down, there, Sparky. You still need to apply my rrd_helpers.c patch
to CVS. :)
I am shifting my focus right now to puttin
matt massie wrote:
guys-
i just got an email from steve saying that solaris looks happy with what
we have in CVS now. unless we hear from steve otherwise, i think we
should release 2.5.0 on monday of next week. i'll try to get the
documentation in order before then.. i know federico has bee
1 - 100 of 195 matches
Mail list logo
