I think thats a great idea.
Which is probably why it already exists... :)
try MON_GROUP and MON_SERVICE
(I see that the documentation doesn't list those for monitors, only
for alerts, but they do exist and work.)
-David
On Wed, Jan 6, 2010 at 1:30 PM, Nathan Gibbs nat...@cmpublishers.com
On Mon, Dec 7, 2009 at 4:51 PM, Alex Dean a...@crackpot.org wrote:
This is using the mon package provided by Ubuntu Karmic (9.10).
# dpkg --list | grep mon
... skipping a bunch of mono stuff ...
ii mon 0.99.2-13ubuntu1
monitor hosts/services/whatever
On Fri, Nov 20, 2009 at 12:28 PM, Anders Synstad ander...@basefarm.no wrote:
On the server side however, the check works as a heartbeat.
Checking if the localservice is still alive. But this is
only performed once every hour.
My suggestion would be to use the 'redistribute' feature that was
There already is support in dns.monitor for recursive server testing.
(I wrote the code)
try dns.monitor -caching_only -query www.yahoo.com:A -query
google.com:MX servername
-David
On Tue, Nov 3, 2009 at 4:11 PM, Nathan Gibbs nat...@cmpublishers.com wrote:
* Kastus Shchuka wrote:
On Tue,
Udo,
Mon depend expressions are perl expressions. You probably want:
depend webservers1:ldap gateway:ping
-David
On Tue, Aug 19, 2008 at 7:23 AM, Udo Rader [EMAIL PROTECTED] wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
I almost don't dare to ask ...
Using the insanely
Rune,
You didn't mention some important bits of imformation, most
significantly what version of Mon, Mon::Client and mon.cgi you are
using. There have been significant protocol changes in various
versions. Speed problems that occurred with 0.99.2 are pretty much
gone with 1.2.0 for example.
On 10/17/07, Jacques Klein [EMAIL PROTECTED] wrote:
Well, not really, or not enough in fact.
If I understand the depend, it's a way to avoid multiple alerts by
specifying dependencies between services in ONE mon.
If I take this concept, then it would have to be extended to
dependencies
--On Thursday, December 14, 2006 00:20:40 +1030 Ben Ragg
[EMAIL PROTECTED] wrote:
Hi there,
We often make changes to our network at 3am, and while every effort is
made to disable the appropriate services, quite often something will slip
through the cracks and wake someone up.
Is there
I sent this earlier, but I must have sent it from the wrong address
and its sitting in a moderation queue...
-David
-- Forwarded message --
From: David Nolan [EMAIL PROTECTED]
Date: Dec 1, 2006 8:27 AM
Subject: Re: Handwritten sms.alert doesn't get executed
To: mon
--On October 13, 2006 9:41:52 AM -0400 Bill Chmura [EMAIL PROTECTED]
wrote:
Hello,
Yesterday I installed two temperature sensors in my server room. I set
them both for 10 degrees higher than the current. Well, the building
people raise the temperature up at night to save on energy.
I
On 9/15/06, Bill Chmura [EMAIL PROTECTED] wrote:
Hey,
I've been muddling my way through getting the SNMP working with Mon, and
I am happy to report that I have had more trouble with finding the right
MIBS than I have with getting MON to work with them. Good job!
Some thoughts after going
On 9/7/06, Bill Chmura [EMAIL PROTECTED] wrote:
If someone wants to update the tag on the mon-client so the new stuff
that fixes mon.cgi is in, I would be more than happy to roll a few
tarballs so there could be a new release.
I'd actually already moved the tag, but was waiting for Jim to
No, Mon does not currently support this format. Using logrotate is
probably an OK approach, but I suspect that you would need to restart
Mon to get it to close the file and create a new one. (Haven't
confirmed that, but I don't think it re-opens the file every time...)
A better answer would be
On 9/8/06, Bill Chmura [EMAIL PROTECTED] wrote:
I've recently spent a lot of time overhauling my mon.cf. I moved to m4
macros which I had been meaning to try (I recommend them to anyone who
has not tried them for mon.cf).
(Note to self: I really need to put together a public release of the
On 9/5/06, Bill Chmura [EMAIL PROTECTED] wrote:
I installed recently the latest cvs (1-2-0) of both the monitor and of
the client.
MON.CGI
---
I put mon.cgi in my web server, but when I run it - basically it spits
out into the logs:
Cannot locate object list_views via package
--On Thursday, August 31, 2006 12:16:25 -0400 Jim Trocki
[EMAIL PROTECTED] wrote:
On Thu, 31 Aug 2006, Bill Chmura wrote:
Which version is recommended at this point?
this should do you well:
ftp://ftp.kernel.org/pub/software/admin/mon/devel
mon-1.1.0pre1.tar.gz
On 9/1/06, Jim Trocki [EMAIL PROTECTED] wrote:
ok sure, and i guess we should just fork it and call the branch 1.2, or 2.0.
the head trunk we can begin calling 1.3 or 2.1, following the odd #s devel,
even #s stable paradigm. i can take care of that and the updates to the web
page and other
--On Thursday, August 24, 2006 14:54:05 -0500 Tim Carr [EMAIL PROTECTED]
wrote:
- Would it be possible to just send one everything is ok trap for a
new overall check? Maybe a new monitor script that queries itself to
see if there are any existing problems and will alert based off that?
-
--On Thursday, August 24, 2006 13:58:49 +0200 Emilio Mira Alfaro
[EMAIL PROTECTED] wrote:
Hi list,
I'm trying to configure mon to alert when one of our routers interfaces
flaps 3 times during 30 secs. I also would like mon not to send more
than 1 alert every 30 minutes I came up with
--On Thursday, August 24, 2006 10:14:48 -0400 Jim Trocki
[EMAIL PROTECTED] wrote:
On Thu, 24 Aug 2006, David Nolan wrote:
--On Thursday, August 24, 2006 08:21:16 -0500 Tim Carr
[EMAIL PROTECTED]
The problem is that we're going to need to turn the monitoring period
for several
--On Thursday, August 24, 2006 10:18:56 -0500 Tim Carr [EMAIL PROTECTED]
wrote:
4000 traps/second. That sounds like a whole lot to me.
Holy cr** thats a lot of traps. Wow, the interesting ways that mon gets
deployed continue to amaze me...
Even if you were only sending one trap per
--On Thursday, July 13, 2006 14:01:58 -0500 Tim Carr [EMAIL PROTECTED]
wrote:
A question on the redistribute option, though - I'm not sure I can
follow how the configuration works. For example, my current remote
server config is:
redistribute is a service level config option, not a
--On Thursday, July 13, 2006 14:20:38 -0500 Tim Carr [EMAIL PROTECTED]
wrote:
Gotcha. I threw that in, and it seems to work correctly, except I can't
tell if it is or not. I'm watching the log file, and it shows alerts
being sent on an up/down event, but I'm not seeing alerts every 15s
On 7/13/06, Tim Carr [EMAIL PROTECTED] wrote:
Here's a bit more information on it. I've got the slave server
configured for multiple services, each of them using the redistribute
option:
redistribute alert trap.alert mainmonitor
If thats an exact quote you've got the option wrong. Its
--On Wednesday, July 05, 2006 13:46:44 +0200 Felix Leiter
[EMAIL PROTECTED] wrote:
mon recognizes at 03:29:37 03:29:47 that the port 8080 is closed and
calls the squid.alert at 03:29:47 but then nothing happens. I don't now
where the misconfiguration is.
I try to change the
of the failure? Was qpage.alert
exiting with an error code that made Mon think it need to re-try the alert?
-David Nolan
Network Software Designer
Computing Services
Carnegie Mellon University
___
mon mailing list
mon@linux.kernel.org
http://linux.kernel.org
. Is your monitor's summary line changing? (That
would cause a re-alert).
-David
David Nolan*[EMAIL PROTECTED]
curses: May you be forced to grep the termcap of an unclean yacc while
a herd of rogue emacs fsck your troff and vgrind your pathalias
30m
Those would run some.alert.script immediately whenever a failure occurs,
and some.other.alert.script after the failure has been continous for half
an hour and every half hour after that.
See the manual for full information on all the alert control semantics that
are available.
-David
scripts are documented in the Mon man
page.
-David
David Nolan*[EMAIL PROTECTED]
curses: May you be forced to grep the termcap of an unclean yacc while
a herd of rogue emacs fsck your troff and vgrind your pathalias
adding the full path to your ssh binary.
-David
David Nolan*[EMAIL PROTECTED]
curses: May you be forced to grep the termcap of an unclean yacc while
a herd of rogue emacs fsck your troff and vgrind your pathalias
to control the ping timeout
behavior:
-r num retry num times for each host before reporting failure
-s num consider hosts which respond in over num msecs failures
-t num wait num msecs before sending retries
-David
David Nolan*[EMAIL
send us the version iformation for you version of fping and
we'll see if we can fix it.
-David
David Nolan*[EMAIL PROTECTED]
curses: May you be forced to grep the termcap of an unclean yacc while
a herd of rogue emacs fsck your troff and vgrind your
it.
CVS is definitely more stable then 0.99.2. 0.99.2 has some nasty bugs,
including some crash and burn type bugs.
I need to spend some time integrating some last bug fixes to CVS and then
we're ready to call it a release.
-David
David Nolan*[EMAIL
[host...]
Any hosts listed after exclude_hosts will be excluded from the service
check.
-David
David Nolan*[EMAIL PROTECTED]
curses: May you be forced to grep the termcap of an unclean yacc while
a herd of rogue emacs fsck your troff and vgrind your
around to looking at the patches yet. (I
guess I was hoping Jim would. He was probably hoping I would... :)
I'll try to look at them this weekend.
-David
David Nolan*[EMAIL PROTECTED]
curses: May you be forced to grep the termcap of an unclean yacc
in the period section will result in an error.
Can you post a snippet of your current config and the resulting error
message?
-David
David Nolan*[EMAIL PROTECTED]
curses: May you be forced to grep the termcap of an unclean yacc while
a herd of rogue
--On Tuesday, October 11, 2005 22:32:51 +0200 [EMAIL PROTECTED] wrote:
Quoting David Nolan :
Sorry to hear your employer ties your hands like that. 0.99.2 has
some
serious problems, including some that can trigger a perl bug that
results
in a perl segfault.
Yeah I know. It's
that I've check says their text messaging service
is for 'entertainment purposes only'. i.e. not reliable for business
purposes.
-David
David Nolan*[EMAIL PROTECTED]
curses: May you be forced to grep the termcap of an unclean yacc while
a herd
syslog.conf to see how logs from daemon are configured.
-David
David Nolan*[EMAIL PROTECTED]
curses: May you be forced to grep the termcap of an unclean yacc while
a herd of rogue emacs fsck your troff and vgrind your pathalias
used it. (I
didn't like the 'must replace syslogd' requirement..)
I have a similar tool which watches the syslog log files and pattern
matches on the output, generating mon traps as necessary. I could probably
add it to the mon CVS area if anyone is interested in using it...
-David
David
seconds, whatever...) then you could
have a trap timeout in Mon to detect when it stopped generating traps.
-David
David Nolan*[EMAIL PROTECTED]
curses: May you be forced to grep the termcap of an unclean yacc while
a herd of rogue emacs fsck your troff
export... I've probably got a dozen or so to add. (Plus the docs for the
monitor-auth.cf syntax...)
-David
David Nolan*[EMAIL PROTECTED]
curses: May you be forced to grep the termcap of an unclean yacc while
a herd of rogue emacs fsck your troff
that
feature as an option and send us a patch.
-David
David Nolan*[EMAIL PROTECTED]
curses: May you be forced to grep the termcap of an unclean yacc while
a herd of rogue emacs fsck your troff and vgrind your pathalias
seconds, check their load average via snmp every 45 seconds, test http
every minute, and test https every five minutes. (And the router between
my monitoring host and the web server is pinged every 15 seconds...)
-David
David Nolan*[EMAIL PROTECTED
which was detected, and is passed to the alert
program. All remaining output is also passed to the alert program, but it
has no required interpretation.
-David
-David Nolan
Network Software Designer
Computing Services
Carnegie Mellon University
section above for a list of the parameters mon will pass
automatically to alert programs.
-David
David Nolan*[EMAIL PROTECTED]
curses: May you be forced to grep the termcap of an unclean yacc while
a herd of rogue emacs fsck your troff and vgrind your
David Nolan*[EMAIL PROTECTED]
curses: May you be forced to grep the termcap of an unclean yacc while
a herd of rogue emacs fsck your troff and vgrind your pathalias!
___
mon mailing list
mon@linux.kernel.org
http
watch,
followed by whitespace and a single word which normally refers to a
pre-defined hostgroup. If the second word is not recognized as a hostgroup
tag, a new hostgroup is created whose tag is that word, and that word is
its only member.
-David
David Nolan
on vacation tomorrow... :)
Sounds like you've got two perl installations on your machine, and the one
that mon is using isn't the one thats in your PATH. Compare the output of
'which perl' and 'head -1 mon'
-David
David Nolan*[EMAIL PROTECTED]
curses
my
problem.
Mon runs as whatever user you chose to run it as. Some places run it as
root, some places run it as another user.
Try running 'ps waux | grep mon' to find what user its running as.
-David
David Nolan*[EMAIL PROTECTED]
curses: May you
be broken. Try
running some other perl scripts.
-David
David Nolan*[EMAIL PROTECTED]
curses: May you be forced to grep the termcap of an unclean yacc while
a herd of rogue emacs fsck your troff and vgrind your pathalias
entry.
Also, you can run mon with debugging enabled, via '-d', to get more status
information which might help track the problem.
-David
David Nolan*[EMAIL PROTECTED]
curses: May you be forced to grep the termcap of an unclean yacc while
a herd
David Nolan*[EMAIL PROTECTED]
curses: May you be forced to grep the termcap of an unclean yacc while
a herd of rogue emacs fsck your troff and vgrind your pathalias!
___
mon mailing list
mon@linux.kernel.org
http
--On Friday, April 08, 2005 6:33 PM -0700 Jim Trocki [EMAIL PROTECTED]
wrote:
On Fri, 8 Apr 2005, David Nolan wrote:
This is a known bug with some regexps in perl's Text::ParseWords that is
tickled by large input from mon.
well it's not really a bug, it's just that the default stack size
to specify a period
definition for something you want to always match seems silly.
-David
David Nolan*[EMAIL PROTECTED]
curses: May you be forced to grep the termcap of an unclean yacc while
a herd of rogue emacs fsck your troff and vgrind your pathalias
.
You probably also want Mon::Client, also available from CPAN, or for
download from the mon download site.
-David
David Nolan*[EMAIL PROTECTED]
curses: May you be forced to grep the termcap of an unclean yacc while
a herd of rogue emacs fsck your troff
addresses,
which one is firing?
-David
David Nolan*[EMAIL PROTECTED]
curses: May you be forced to grep the termcap of an unclean yacc while
a herd of rogue emacs fsck your troff and vgrind your pathalias
alertevery 1m
You also might want an upalert entry in the second period that would bring
the heartbeat service back up.
-David
David Nolan*[EMAIL PROTECTED]
curses: May you be forced to grep the termcap of an unclean yacc while
a herd of rogue emacs
-cvsweb-markup
-David
David Nolan*[EMAIL PROTECTED]
curses: May you be forced to grep the termcap of an unclean yacc while
a herd of rogue emacs fsck your troff and vgrind your pathalias!
___
mon mailing list
-1.1.0pre1, available from
http://sourceforge.net/projects/mon/ or
ftp://ftp.kernel.org/pub/software/admin/mon/devel/
-David
David Nolan*[EMAIL PROTECTED]
curses: May you be forced to grep the termcap of an unclean yacc while
a herd of rogue emacs fsck
--On Thursday, March 24, 2005 10:30 PM -0800 Michael Vogt
[EMAIL PROTECTED] wrote:
Not sure if this has been reported.
It is not fixed in mon-1.0.0pre5.
Also already fixed in mon-1.1.0pre1.
-David
David Nolan*[EMAIL PROTECTED]
curses: May you be forced
operation.
-David
David Nolan*[EMAIL PROTECTED]
curses: May you be forced to grep the termcap of an unclean yacc while
a herd of rogue emacs fsck your troff and vgrind your pathalias!
___
mon mailing list
mon
reading through
all the changes at the time to make sure I wasn't breaking anything. I
also went through and essentially cleared out the pending sourceforge bug
queue at the time, because it hadn't been monitored or updated in a long
time.
-David
David Nolan
. In particular I can enable
two-way messaging, to allow our coverage people to reply to an alert from
the pager.
-David
David Nolan*[EMAIL PROTECTED]
curses: May you be forced to grep the termcap of an unclean yacc while
a herd of rogue emacs fsck your troff
phone directly with a modem. Even if you don't put in a fancy
text to speech system, if callerID works your admins can know Hey, Mon is
calling, that must mean I missed an alert... If you've got a better
secondary alert mechanism, use that instead.
-David
David Nolan
;
#print STDERR $server: success!\n;
};
And you need to add one line to Net::SNPP to add the non-standard RPLY
command:
sub _RPLY { shift-command(RPLY, @_)-response() == CMD_OK }
-David
David Nolan*[EMAIL PROTECTED]
curses: May you be forced to grep
is that the source IP address of the
trap isn't being filled in.
Are there any other log messages? And can you provide a bit more detail on
the exact failure behavior you see? I assume that mon is just ignoring the
trap completely. Does it just ignore certain traps, or all of them?
-David
David Nolan
which took a port number as one option, and a read the list of real servers
to enable/disable from the summary line. Then you could group the hosts
together in the way that makes the monitoring solution much more elegant,
especially when you start moving beyond two servers in the pool.
-David
environment variable that is passed to monitor scripts to find
the files.
The primary reason that daemons change their working directory is avoid
having a running daemon have its working directory in a network mounted
filesystem, or in a filesystem you might want to unmount.
-David
David Nolan
between two mon servers, but it could be
used for your function just as easily.
(Though I just realized I need to add documentation for this option. I
thought I'd done that already...)
-David Nolan
Network Software Designer
Computing Services
Carnegie Mellon University
we use to verify that the host is responding to snmp, and
test the load average.)
-David Nolan
Network Software Designer
Computing Services
Carnegie Mellon University
___
mon mailing list
mon@linux.kernel.org
http://linux.kernel.org/mailman/listinfo/mon
David Nolan*[EMAIL PROTECTED]
curses: May you be forced to grep the termcap of an unclean yacc while
a herd of rogue emacs fsck your troff and vgrind your pathalias!
___
mon mailing list
[EMAIL PROTECTED]
http
--On Monday, November 15, 2004 10:54 AM -0700 Shea Frederick
[EMAIL PROTECTED] wrote:
Fixed that, but still not creating a log file.
logdir = /var/log/mon
dtlogfile = dtlog
Ah, I think you also need:
dtlogging = 1
(Forgot about that setting...)
-David
David Nolan
I was wondering if anyone else from the list is attending LISA '04 in
Atlanta this week? I'll be down there Tuesday night through Friday. At
last year's conference we had a very well attended Mon BOF. If there's
enough interest I could arrange to have a BOF session again...
-David
David
.
LooperNG looks like it might be useful for translating SNMP traps into mon
events, but doesn't currently have native support for sending stuff to Mon.
(They already provide a mon alert script to generate send events to
LooperNG, but no vice-versa.)
-David
David Nolan
would work reasonably. Or if you're willing
to wait a day or so, I think I'm going to try to implement this for my
system, and I'd be happy to post the script I use and the resulting config
blocks as well.
-David
David Nolan*[EMAIL PROTECTED]
curses: May
mon.cgi, it provides a 'Test Mon Config File' option, or
you can just run moncmd, with the arguments 'test config'.
This has always been good enough for my needs, since I always have mon
running. But if you require the feature you describe, I could add it
fairly easily.
-David Nolan
Network
the data in a database, and generate
mon.cf files from that database.
And one of these days I swear I'm going to have the time to write some
documentation so I can get it released... Unfortunately I've been saying
that for over a year.
-David Nolan
Network Software Designer
Computing Services
like it would make the 'test and reload' operation both
expensive, and unpredictable, since the file would be generated twice, and
not guaranteed to be the same.
-David Nolan
Network Software Designer
Computing Services
Carnegie Mellon University
of the Net::DNS package. We use it extensively to do thousands of
DDNS updates a day to our zones.
-David
David Nolan*[EMAIL PROTECTED]
curses: May you be forced to grep the termcap of an unclean yacc while
a herd of rogue emacs fsck your troff
--On Thursday, September 16, 2004 11:02 AM -0700 Augie [EMAIL PROTECTED]
wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Back in 2001 Ed Ravin said the following:
http://www.mail-archive.com/[EMAIL PROTECTED]/msg00014.html
I'm thinking of coding a patch to mon to include the state of ACK'd
it should look like, please either post the
output or send it to me personally if you're concerned about posting the
data.
-David Nolan
Network Software Designer
Computing Services
Carnegie Mellon University
___
mon mailing list
[EMAIL PROTECTED]
http
notice this and
complain is a bug.)
-David
David Nolan*[EMAIL PROTECTED]
curses: May you be forced to grep the termcap of an unclean yacc while
a herd of rogue emacs fsck your troff and vgrind your pathalias
PATH or fully specifying the path to some program.
-David
David Nolan*[EMAIL PROTECTED]
curses: May you be forced to grep the termcap of an unclean yacc while
a herd of rogue emacs fsck your troff and vgrind your pathalias
--On Wednesday, July 07, 2004 11:26 AM -0700 Eric Sorenson
[EMAIL PROTECTED] wrote:
I got frustrated trying to show someone how to install mon, so I rewrote
chunks of the INSTALL doc to match reality. Apply or ignore as you see
fit.
Excellent, thanks.
Jim, I'll apply these.
-David
David Nolan
had the same problem before using perl's ping module and trying to do
an icmp ping...
This wouldn't be solvable without using suidperl, which introduces a whole
slew of other issues.
-David
David Nolan*[EMAIL PROTECTED]
curses: May you be forced to grep
--On Monday, June 28, 2004 3:36 PM -0400 Jim Trocki [EMAIL PROTECTED]
wrote:
On Mon, 28 Jun 2004, David Nolan wrote:
While it doesn't add any bugs, I don't believe it fixes any either.
it does indeed fix the bug where a received would not reset the
_trap_timer, preventing traptimeout from
will be sent until that much time has passed again.
Does that help?
-David Nolan
Network Software Designer
Computing Services
Carnegie Mellon University
___
mon mailing list
[EMAIL PROTECTED]
http://linux.kernel.org/mailman/listinfo/mon
for saving
and restoring the full opstatus. However your question lead me to look at
that code and notice that trap_timer isn't saved in the current code. I'll
fix that and commit it shortly. (We don't use trap timeouts very much, so
I'd never noticed before.)
-David
David Nolan
will not happen when traps are recieved while the
scheduler is stopped, but the traps be processed, and their information will
show in the user interface. (But any non-trap services will obviously not
be running, and stale data will sit around.)
-David
David Nolan
everyone about everything.
STOP!. Thus all things directly monitored should stop being monitored,
and abolutely no alerts should be generated for any reason.
Thats basically what I made it do.
-David
David Nolan*[EMAIL PROTECTED]
curses: May you be forced to grep
-devel-1.1.X branch available.
(Of course, I'm about to head to conferences for two weeks. Anyone on the
list going to be at Usenix?)
-David
David Nolan*[EMAIL PROTECTED]
curses: May you be forced to grep the termcap of an unclean yacc while
a herd
--On Monday, June 07, 2004 1:32 PM -0700 Jim Trocki [EMAIL PROTECTED]
wrote:
On Thu, 3 Jun 2004, David Nolan wrote:
(In fact, I may have posted it to the list, but I can't recall
right now. Time for some email archeology.)
ahh, i apologize for my confusion. clearly my recollection was faulty
and release CMU-Mon
as a fork, but maybe I should. Part of the reason the NetSage
monconfiguration system hasn't been released yet is that its really
designed to take advantage of all the features I added.
-David
David Nolan*[EMAIL PROTECTED]
curses: May you
--On Thursday, June 03, 2004 10:52 AM -0700 Jim Trocki
[EMAIL PROTECTED] wrote:
this is a matter of historical record which should be public. rather
than post his patched version to the mailing list for everyone to have a
gander at and do something with if they chose, he sent them only to me
and hitting
attachments as well.
David Nolan
Network Software Developer
Computing Services
Carnegie Mellon University
___
mon mailing list
[EMAIL PROTECTED]
http://linux.kernel.org/mailman/listinfo/mon
whether
sourceforge is the best option, but ultimately I don't care as long as it
works.
David Nolan
Network Software Developer
Computing Services
Carnegie Mellon University
___
mon mailing list
[EMAIL PROTECTED]
http://linux.kernel.org/mailman/listinfo/mon
is to eliminate the usage of that perl
module. I've done that in my local version of Mon and the performance
improvement was incredible. There are other reasons to eliminate that
module anyway (it can cause perl to segfault). If you're interested in
those patches, let me know.
-David
David Nolan
of Mon for 1.5 years, but
that I haven't submitted to Jim because he hasn't released the last set of
patches I sent him.)
-David
David Nolan*[EMAIL PROTECTED]
curses: May you be forced to grep the termcap of an unclean yacc while
a herd of rogue
*really* need a new stable
release of Mon. I hope this is fixed in the development version, but I
haven't personally tested it, as my Mon infrastructure is heavily dependent
on the changes I've made to Mon, and Jim hasn't yet applied any of the
patches I've sent him, as far as I know.
-David
1 - 100 of 126 matches
Mail list logo
