mon-devel Mailing List for mon
Brought to you by:
trockij
You can subscribe to this list here.
2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(3) |
Jul
(13) |
Aug
(6) |
Sep
|
Oct
|
Nov
|
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2005 |
Jan
|
Feb
(27) |
Mar
|
Apr
(9) |
May
(11) |
Jun
|
Jul
(4) |
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
(15) |
2006 |
Jan
|
Feb
(6) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2007 |
Jan
|
Feb
|
Mar
(14) |
Apr
(4) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(6) |
Nov
(4) |
Dec
(8) |
2008 |
Jan
(6) |
Feb
(4) |
Mar
(7) |
Apr
|
May
|
Jun
(2) |
Jul
(1) |
Aug
|
Sep
|
Oct
(2) |
Nov
(1) |
Dec
|
2009 |
Jan
(1) |
Feb
(1) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(3) |
2010 |
Jan
(11) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(7) |
Nov
(7) |
Dec
|
2012 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(1) |
Nov
(1) |
Dec
|
2013 |
Jan
|
Feb
(3) |
Mar
|
Apr
(1) |
May
(1) |
Jun
(1) |
Jul
(1) |
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
2014 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2015 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
From: Nathan G. <na...@cm...> - 2017-09-08 03:46:02
|
Finally, after 3 years+ ! Released a new version of our mon.cgi. Should now run correctly under perl 5.16+ and CGI 4.04+ http://www.cmpublishers.com/oss/mon.shtml#moncgi Enjoy. :-) -- Sincerely, Nathan Gibbs Systems Administrator Christ Media http://www.cmpublishers.com |
From: Nathan G. <na...@cm...> - 2015-02-19 05:32:51
|
Hi all, Does anyone have an idea of what a sane number would be for I/O errors including discards, on a network interface in, say a five minute period. One of our systems recently had a NIC failure. I spent over an hour swapping cables, messing with switch & firewall settings, etc. Finally, I happened to try looking at the NICs on the failing system via SNMP. What I saw was a system with 2 NIC's functioning perfectly, and one NIC with an error count of over 400,000. Obviously, a hardware failure & something that mon could cover. :-) I'd like to be sure that the default value for acceptable error counts is something sensible before releasing the monitor for this. Currently I have a default of 1000. There is also the idea of a baseline acceptable error count that could scale based on the interface type detected, as a faster interface could experience more errors in a shorter amount of time. Any thoughts, ideas, or recommendations for a base acceptable error count? Thanks :-) -- Sincerely, Nathan Gibbs Systems Administrator Christ Media http://www.cmpublishers.com |
From: Nathan G. <na...@cm...> - 2014-02-10 23:34:19
|
Finally, after 2 years+ ! Released a new version of our mon.cgi http://www.cmpublishers.com/oss/mon.shtml#moncgi Enjoy. :-) -- Sincerely, Nathan Gibbs Systems Administrator Christ Media http://www.cmpublishers.com |
From: Jim T. <tr...@gm...> - 2013-08-04 18:13:11
|
On Wed, 31 Jul 2013, Marco Bozzolan wrote: > > Hello, > > I have just noticed that the main website for mon: > > https://mon.wiki.kernel.org/ > > is now redirecting to SourceForge, at > > https://sourceforge.net/projects/mon/ > > so that all the wiki contents are not available anymore. > > Is there any chance those contents can be recovered and republished on > the SourceForge wiki? Yes, I have an XML dump of the contents of the wiki, and the intention is to transplant it into the sf environment. |
From: Marco B. <ma...@s1...> - 2013-07-31 14:38:45
|
Hello, I have just noticed that the main website for mon: https://mon.wiki.kernel.org/ is now redirecting to SourceForge, at https://sourceforge.net/projects/mon/ so that all the wiki contents are not available anymore. Is there any chance those contents can be recovered and republished on the SourceForge wiki? If any conversion work has to be done, I wouldn't mind spending some time for it. Regards -- http://s19n.net |
From: Nathan G. <na...@cm...> - 2013-06-18 16:47:25
|
Hi all, We've moved all the mon stuff on our site from the general Open Source Software page to its own Mon specific page. http://www.cmpublishers.com/oss/mon.shtml Thanks and enjoy, -- Sincerely, Nathan Gibbs Systems Administrator Christ Media http://www.cmpublishers.com |
From: Nathan G. <na...@cm...> - 2013-05-01 01:38:33
|
Hi all, I was checking up on the status of the bbmon.cgi project at loplop.net and discovered that it's not there anymore. I've been siting on a rewrite since 2010, as Nicolas indicated that he planned to publish our changes in an updated version. I'd hate for the community to lose this software so I've put our version up at: http://www.cmpublishers.com/oss/#bbmoncgi Thanks Nicolas for a cool Web interface to mon. -- Sincerely, Nathan Gibbs Systems Administrator Christ Media http://www.cmpublishers.com |
From: Nathan G. <na...@cm...> - 2013-04-23 16:21:30
|
Just released a bug fix version of our replacement mail.alert script. http://www.cmpublishers.com/oss/#mail.alert The service name wasn't being put into the subject line of the email alerts. OOPS :-( Fixed Now :-) Enjoy. :-) -- Sincerely, Nathan Gibbs Systems Administrator Christ Media http://www.cmpublishers.com |
From: Nathan G. <na...@cm...> - 2013-02-22 19:37:29
|
On 2/22/2013 1:44 PM, Andrew Siegel wrote: > Hi Nathan, > > Thanks for making this available. I don't know if anyone else mentioned > it, but the mail.alert link on the page actually references the > snmpinv.monitor modules mentioned on the lines above. > > Andy > > -- > Andrew Siegel AAAH! I can't believe I did that! Its fixed now. LOL! :-) :$ Thanks Andrew. I appreciate it. :$ :-) -- Sincerely, Nathan Gibbs Systems Administrator Christ Media http://www.cmpublishers.com |
From: Nathan G. <na...@cm...> - 2013-02-22 16:50:39
|
Just released our version of the mail.alert script that ships with the mon software. http://www.cmpublishers.com/oss/#mail.alert After seeing mon-Bugs-3605484 yesterday, I remembered that we have been running a modified mail.alert for the last couple of years. Yesterday, I reviewed & documented these changes in addition to fixing bug 3605484. Enjoy. :-) -- Sincerely, Nathan Gibbs Systems Administrator Christ Media http://www.cmpublishers.com |
From: Jonathan <jdc...@gm...> - 2013-02-21 22:23:48
|
Hey all: I just tried to download version 1.2 off the website, and the download links are broken. ftp.kernel.org doesn't have the latest files, I had to go to sourceforge to find them. I'm not sure if the CVS version is better to install, but if it is that should probably mentioned on the download page somewhere. Also, the last 2 edits on the main page of the wiki have been spam-edits for "essay services" and should probably be removed: https://mon.wiki.kernel.org/index.php/Main_Page Thanks for a great piece of software! Jonathan |
From: Timothy Lu Hu B. <ti...@su...> - 2012-11-27 21:37:47
|
the standard http.monitor wasn't cutting it so i modified it and have been using it like this a while . the major modifications are : 1) regex to match against for (did i do that ? don't remember , but i might have .. the diff from cvs seems to not have it , but i don't remember ... i'll bet trockij did it and i'm trying to steal it but this would be better if mon was rehosted in github) 2) logging so that if there is a failure condition i have a log of what mon saw to kick back to developers 3) HTTP BASIC AUTH support for a bit i sat and tried to make a diff against what's in the cvs ... and it's not very good . i think the regex stuff came into that file 1.1.1.1.4.1 but ... that's not what's in the cvs . so find attached both the file itself and a patch . --timball -- "[]x[][][][][][][][]" || 202-250-0211 [fon] || timmyball [aim] [sunlight foundation] [fb] [twtrr] [utube] [join] [rss] |
From: Nathan G. <na...@cm...> - 2012-10-17 19:04:17
|
Just released an SNMP Inventory monitor. http://www.cmpublishers.com/oss/#snmpinv.monitor Not really a monitor, just a quick way to do an SNMP inventory of everything in a group. Enjoy. -- Sincerely, Nathan Gibbs Systems Administrator Christ Media http://www.cmpublishers.com |
From: Nathan G. <na...@cm...> - 2012-09-12 17:40:51
|
Just updated the snmpdiskspace & snmpnetdisk monitors. http://www.cmpublishers.com/oss/#dns-gtld.monitor snmpnetdisk Fixed error on multiple network mounts when a specific mount point was. specified. All Code & output cleanup. More Debug info. Enjoy. -- Sincerely, Nathan Gibbs Systems Administrator Christ Media http://www.cmpublishers.com |
From: Nathan G. <na...@cm...> - 2012-05-16 19:11:31
|
Just updated the dns-gtld monitor. http://www.cmpublishers.com/oss/#dns-gtld.monitor Code & Output Polishing Added an option to disable complete TLD NS checking Reverse zone filtering. Domain NS sanity checks. Glue record consistency check. Massive thanks to sourceforge user gulikoza for these great ideas and code. Enjoy. -- Sincerely, Nathan Gibbs Systems Administrator Christ Media http://www.cmpublishers.com |
From: Jim T. <tr...@gm...> - 2011-11-18 15:09:17
|
On Fri, 18 Nov 2011, Anders Synstad wrote: >>> We had the problem some years ago. We fixed it and I sent a patch. It >>> seems it was never integrated to the source. >> >> this fix has been in cvs under the mon-1-2-branch branch, along with >> some other more recent fixes which affect the process handling. so, i'd >> recommend that Anders check out that branch from cvs and give it a try. > > We're currently running the 1.2.0 release of mon, but if I understand you > correctly, the fix didn't make the 1.2.0 release, but is available in the the > cvs branch. correct. cvs -d:pserver:ano...@mo...:/cvsroot/mon login (hit return for password) cvs -z3 -d:pserver:ano...@mo...:/cvsroot/mon co -P -rmon-1-2-branch mon > On a side note; the more I've been looking at other monitoring systems, the > more I love mon. that's good to hear. whatever works is best. |
From: Anders S. <and...@ba...> - 2011-11-18 14:56:30
|
>> We had the problem some years ago. We fixed it and I sent a patch. It >> seems it was never integrated to the source. > > this fix has been in cvs under the mon-1-2-branch branch, along with > some other more recent fixes which affect the process handling. so, i'd > recommend that Anders check out that branch from cvs and give it a try. We're currently running the 1.2.0 release of mon, but if I understand you correctly, the fix didn't make the 1.2.0 release, but is available in the the cvs branch. Will check it out. On a side note; the more I've been looking at other monitoring systems, the more I love mon. Regards Anders Synstad Basefarm AS |
From: Jim T. <tr...@gm...> - 2011-11-18 14:42:14
|
On Fri, 18 Nov 2011, den...@or... wrote: > Hello, > > We had the problem some years ago. We fixed it and I sent a patch. It seems it was never integrated to the source. this fix has been in cvs under the mon-1-2-branch branch, along with some other more recent fixes which affect the process handling. so, i'd recommend that Anders check out that branch from cvs and give it a try. |
From: Anders S. <and...@ba...> - 2011-11-18 10:55:05
|
Thank you Denis, I'll look into this as soon as I can. I does seem very plausible that this is what could be happening. Regards, Anders Synstad Basefarm AS ________________________________________ From: den...@or... [den...@or...] Sent: Friday, November 18, 2011 11:49 AM To: Anders Synstad; mon...@li... Subject: RE: [Mon-devel] mon "fork bomb" Hello, We had the problem some years ago. We fixed it and I sent a patch. It seems it was never integrated to the source. The problem is due to the fact that sometime the 'exec' function call used to run a monitor or an alert script *does* return. It should not. It's written in the 'exec' documentation. There is even a warning about adding something other than exit after an exec: exec LIST exec PROGRAM LIST The "exec" function executes a system command and never returns-- use "system" instead of "exec" if you want it to return. It fails and returns false only if the command does not exist and it is executed directly instead of via your system's command shell (see below). Since it's a common mistake to use "exec" instead of "system", Perl warns you if there is a following statement which isn't "die", "warn", or "exit" (if "-w" is set - but you always do that). The 'exec' is called in a forked process and should replace that forked process by the monitor or the alert. The 'exec' can fail (and thus return) when there is some ressources missing (we where short on memory when this happened). But it could also happen if you delete a monitor or alert scripts (looking for scripts is done only at startup). In the 'mon' code, there is a 'return' after the call to 'exec'. That's bad. As the exec should never return, we must put an 'exit' after. Without the 'exit', the code symply returns to the main loop and we have a forked version of mon running in parallel with the parent one. Here is the patch we've written to solve this issue. diff -Naur mon-1.2.0/mon mon-1.2.0-bugexec/mon --- mon-1.2.0/mon 2009-12-16 13:46:33.808765600 +0000 +++ mon-1.2.0-bugexec/mon 2009-12-16 13:53:04.613773000 +0000 @@ -3611,9 +3611,12 @@ if (!exec @args) { - syslog ('err', "could not exec '@args': $!"); + syslog ('err', "run_monitor: could not exec '@args': $!"); exit (1); } + syslog ('err', + "run_monitor: (unreachable!) could not exec '@args': $!"); + exit(1); } $sref->{"_last_check"} = scalar (time); @@ -5078,10 +5081,12 @@ } if (!exec @execargs) { - syslog ('err', "could not exec alert $alert: $!"); - return undef; + syslog ('err', "call_alert: could not exec alert $alert: $!"); + exit(1); } - exit; + syslog ('err', + "call_alert: (unreachable!) could not exec alert $alert: $!"); + exit(1); } I hope this will help. Denis Choulette den...@or... Equant France CS&O/ITD/France Customer Application Management/Transversal Activities/Service Assurance & Financial Management BP 91235 Rue de la Touche Lambert Bâtiment 7 F35512 Cesson Sévigné Cedex France Phone: +33 (0) 2 23 28 41 09 Fax: +33 (0) 2 23 28 45 83 http://www.equant.com -----Original Message----- From: Anders Synstad [mailto:and...@ba...] Sent: 17 November 2011 10:38 To: mon...@li... Subject: [Mon-devel] mon "fork bomb" Hello, We've been running mon for a decade now, and it's been working great. However, the last month we've started to run into a problem. The best explaination I have is that mon "fork bombs", and the load goes thru the roof. I've only been able to do a dump of ps before we had to reboot the system, and it lists: 365 of these: qroot 607 0.0 3.0 225952 124644 ? S 13:36 0:00 /local/bin/perl /local/etc/mon/mon -l -f -c /etc/mon/mon.cf -P /var/run/mon.pid root 3044 2.6 3.3 225952 137156 ? D 13:38 0:09 /local/bin/perl /local/etc/mon/mon -l -f -c /etc/mon/mon.cf -P /var/run/mon.pid and 1684 of these: root 3043 0.7 0.0 0 0 ? Z 13:38 0:02 [mon] <defunct> This week is has happened 3 times already. This is something I've haven't seen in the past. During normal use, it doesn't seem to be overloaded: root@mon03.osl mon]# free total used free shared buffers cached Mem: 4040056 1654504 2385552 0 68576 1119588 -/+ buffers/cache: 466340 3573716 Swap: 4192944 0 4192944 [root@mon03.osl mon]# uptime 10:10am up 1:11, 5 users, load average: 3.11, 3.05, 2.77 I'm still trying to debug whenever this happens, but there is limits to how long we can debug each time as monitoring is down in this period, and deubgging with triple-digit load time is tideous. I haven't found any indicators in any logfiles either. Does anyone have any ideas what could be causing this? -- Anders Synstad Basefarm AS ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d _______________________________________________ Mon-devel mailing list Mon...@li... https://lists.sourceforge.net/lists/listinfo/mon-devel _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorization. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, France Telecom - Orange shall not be liable if this message was modified, changed or falsified. Thank you. |
From: <den...@or...> - 2011-11-18 10:50:48
|
Hello, We had the problem some years ago. We fixed it and I sent a patch. It seems it was never integrated to the source. The problem is due to the fact that sometime the 'exec' function call used to run a monitor or an alert script *does* return. It should not. It's written in the 'exec' documentation. There is even a warning about adding something other than exit after an exec: exec LIST exec PROGRAM LIST The "exec" function executes a system command and never returns-- use "system" instead of "exec" if you want it to return. It fails and returns false only if the command does not exist and it is executed directly instead of via your system's command shell (see below). Since it's a common mistake to use "exec" instead of "system", Perl warns you if there is a following statement which isn't "die", "warn", or "exit" (if "-w" is set - but you always do that). The 'exec' is called in a forked process and should replace that forked process by the monitor or the alert. The 'exec' can fail (and thus return) when there is some ressources missing (we where short on memory when this happened). But it could also happen if you delete a monitor or alert scripts (looking for scripts is done only at startup). In the 'mon' code, there is a 'return' after the call to 'exec'. That's bad. As the exec should never return, we must put an 'exit' after. Without the 'exit', the code symply returns to the main loop and we have a forked version of mon running in parallel with the parent one. Here is the patch we've written to solve this issue. diff -Naur mon-1.2.0/mon mon-1.2.0-bugexec/mon --- mon-1.2.0/mon 2009-12-16 13:46:33.808765600 +0000 +++ mon-1.2.0-bugexec/mon 2009-12-16 13:53:04.613773000 +0000 @@ -3611,9 +3611,12 @@ if (!exec @args) { - syslog ('err', "could not exec '@args': $!"); + syslog ('err', "run_monitor: could not exec '@args': $!"); exit (1); } + syslog ('err', + "run_monitor: (unreachable!) could not exec '@args': $!"); + exit(1); } $sref->{"_last_check"} = scalar (time); @@ -5078,10 +5081,12 @@ } if (!exec @execargs) { - syslog ('err', "could not exec alert $alert: $!"); - return undef; + syslog ('err', "call_alert: could not exec alert $alert: $!"); + exit(1); } - exit; + syslog ('err', + "call_alert: (unreachable!) could not exec alert $alert: $!"); + exit(1); } I hope this will help. Denis Choulette den...@or... Equant France CS&O/ITD/France Customer Application Management/Transversal Activities/Service Assurance & Financial Management BP 91235 Rue de la Touche Lambert Bâtiment 7 F35512 Cesson Sévigné Cedex France Phone: +33 (0) 2 23 28 41 09 Fax: +33 (0) 2 23 28 45 83 http://www.equant.com -----Original Message----- From: Anders Synstad [mailto:and...@ba...] Sent: 17 November 2011 10:38 To: mon...@li... Subject: [Mon-devel] mon "fork bomb" Hello, We've been running mon for a decade now, and it's been working great. However, the last month we've started to run into a problem. The best explaination I have is that mon "fork bombs", and the load goes thru the roof. I've only been able to do a dump of ps before we had to reboot the system, and it lists: 365 of these: qroot 607 0.0 3.0 225952 124644 ? S 13:36 0:00 /local/bin/perl /local/etc/mon/mon -l -f -c /etc/mon/mon.cf -P /var/run/mon.pid root 3044 2.6 3.3 225952 137156 ? D 13:38 0:09 /local/bin/perl /local/etc/mon/mon -l -f -c /etc/mon/mon.cf -P /var/run/mon.pid and 1684 of these: root 3043 0.7 0.0 0 0 ? Z 13:38 0:02 [mon] <defunct> This week is has happened 3 times already. This is something I've haven't seen in the past. During normal use, it doesn't seem to be overloaded: root@mon03.osl mon]# free total used free shared buffers cached Mem: 4040056 1654504 2385552 0 68576 1119588 -/+ buffers/cache: 466340 3573716 Swap: 4192944 0 4192944 [root@mon03.osl mon]# uptime 10:10am up 1:11, 5 users, load average: 3.11, 3.05, 2.77 I'm still trying to debug whenever this happens, but there is limits to how long we can debug each time as monitoring is down in this period, and deubgging with triple-digit load time is tideous. I haven't found any indicators in any logfiles either. Does anyone have any ideas what could be causing this? -- Anders Synstad Basefarm AS ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d _______________________________________________ Mon-devel mailing list Mon...@li... https://lists.sourceforge.net/lists/listinfo/mon-devel _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorization. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, France Telecom - Orange shall not be liable if this message was modified, changed or falsified. Thank you. |
From: Anders S. <and...@ba...> - 2011-11-17 09:51:22
|
Hello, We've been running mon for a decade now, and it's been working great. However, the last month we've started to run into a problem. The best explaination I have is that mon "fork bombs", and the load goes thru the roof. I've only been able to do a dump of ps before we had to reboot the system, and it lists: 365 of these: qroot 607 0.0 3.0 225952 124644 ? S 13:36 0:00 /local/bin/perl /local/etc/mon/mon -l -f -c /etc/mon/mon.cf -P /var/run/mon.pid root 3044 2.6 3.3 225952 137156 ? D 13:38 0:09 /local/bin/perl /local/etc/mon/mon -l -f -c /etc/mon/mon.cf -P /var/run/mon.pid and 1684 of these: root 3043 0.7 0.0 0 0 ? Z 13:38 0:02 [mon] <defunct> This week is has happened 3 times already. This is something I've haven't seen in the past. During normal use, it doesn't seem to be overloaded: root@mon03.osl mon]# free total used free shared buffers cached Mem: 4040056 1654504 2385552 0 68576 1119588 -/+ buffers/cache: 466340 3573716 Swap: 4192944 0 4192944 [root@mon03.osl mon]# uptime 10:10am up 1:11, 5 users, load average: 3.11, 3.05, 2.77 I'm still trying to debug whenever this happens, but there is limits to how long we can debug each time as monitoring is down in this period, and deubgging with triple-digit load time is tideous. I haven't found any indicators in any logfiles either. Does anyone have any ideas what could be causing this? -- Anders Synstad Basefarm AS |
From: Nathan G. <na...@cm...> - 2011-11-11 23:56:35
|
On 10/19/2011 7:30 PM, Jim Trocki wrote: > On Mon, 17 Oct 2011, Kastus wrote: > >> Hi, >> >> I apologize if I am asking something obvious. >> >> Does anybody know what happened to Mon wiki? It seems like everything is gone >> from http://www.kernel.org/software/mon/, and https://mon.wiki.kernel.org/index.php/ >> looks dead too. > > The wiki will be restored, but that task is blocked while waiting for some > new hardware. > It appears up now. Finally. > The mailing list will be migrated elsewhere, to where I'm not yet sure. > Oh did that get toasted? Let me know where / when I've got a new monitor, and some monitor tweaks ready. -- Sincerely, Nathan Gibbs Systems Administrator Christ Media http://www.cmpublishers.com |
From: Jim T. <tr...@gm...> - 2011-10-19 23:37:00
|
On Mon, 17 Oct 2011, Kastus wrote: > Hi, > > I apologize if I am asking something obvious. > > Does anybody know what happened to Mon wiki? It seems like everything is gone > from http://www.kernel.org/software/mon/, and https://mon.wiki.kernel.org/index.php/ > looks dead too. The wiki will be restored, but that task is blocked while waiting for some new hardware. The mailing list will be migrated elsewhere, to where I'm not yet sure. |
From: Jim T. <tr...@gm...> - 2011-10-17 21:53:06
|
On Mon, 17 Oct 2011, Kastus wrote: > Hi, > > I apologize if I am asking something obvious. > > Does anybody know what happened to Mon wiki? It seems like everything is gone > from http://www.kernel.org/software/mon/, and https://mon.wiki.kernel.org/index.php/ > looks dead too. > > Was it migrated somewhere after attacks on kernel.org or was it simply > shut down? It's been shut down and needs to be migrated to somewhere. |
From: Kastus <ks...@tp...> - 2011-10-17 18:57:29
|
Hi, I apologize if I am asking something obvious. Does anybody know what happened to Mon wiki? It seems like everything is gone from http://www.kernel.org/software/mon/, and https://mon.wiki.kernel.org/index.php/ looks dead too. Was it migrated somewhere after attacks on kernel.org or was it simply shut down? Thanks, Kastus |