ANNOUCE: Loggerithim 6.4.1
Loggerithim is a package for monitoring, visualizing, and managing your systems using remote agents and a web interface. Changes in this version: Frontend: - Remove some unnecessary code from Lists object. - Bring Commander up-to-date with Agent interface Agent: - Fix issues with agent's ftp_putfile task - Add support for 'qfe' cards in Solaris - Add experimental solaris_devices plugin for CPU info and disk error detection - misc cleanups For more information visit: http://www.loggerithim.org Cory 'G' Watson http://www.loggerithim.org -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
ANNOUNCE: Loggerithim 6.4.0
Loggerithim is a package for monitoring, visualizing, and managing your systems using remote agents and a web interface. Changes in this version: - Autoconf make installer - New agent (Solaris and Linux) utilizing SSL for communication - Group based permissions - Improvements to graphing code (filled graphs, multiple Y-axes, multiple keys) - Graph annotations - 'Advanced' menu for custom graphs - Performance improvements (both backend and rendering) It has been quite a while since the last release, as the new agent and metric receiving code required quite a bit of development. There are likely some rough edges, but they will be quickly smoothed. For more information, visit: http://www.loggerithim.org Cory 'G' Watson http://www.loggerithim.org -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Odd Reload Behavior
On Sat, 2003-08-16 at 01:46, Cory 'G' Watson wrote: Well, first of all, you're just asking for trouble if you turn on PerlFreshRestart. Don't do it. I forget why I added it. My (poor) memory seems to recall something from the Eagle book causing me to add it. I'd never seen the 'evil' document before this weekend. My Eagle book is at the office, and I don't recall reading about it in the new Horse book. Do you hava anything like a PerlModule App in your httpd.conf? You haven't actually shown us your real conf, startup, or code, so I'm just guessing here. No, I only had a 'use App;' in my startup. Are you no longer having problems now that you turned off PerlFreshRestart? The problem has since gone away. I accidentally only replied to Ged Haywood when I got the thing working. When I added a caller() to the top of my module, I saw the initial startup.pl use(), and then a later eval() that I couldn't track. When I turned OFF PerlFreshRestart, the order was reversed (eval() before startup.pl's use()) and my problem, of course, went away. I assumed from the beginning that this was something of my own doing, I just wanted to know why my ignorance was causing to happen. It seems that PerlFreshRestart causes some difference in the loading of my modules. -- Cory 'G' Watson http://www.loggerithim.org -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Odd Reload Behavior
On Friday, August 15, 2003, at 06:23 PM, Ged Haywood wrote:
Ignore syntax errors and lack of declarations, as I just threw that
together from memory
The guesswork would be a lot easier if it didn't involve so much
guesswork. :)
I think the root question of my email was lost in my poor explanation.
Basically, I have a module (which I called App) that has something like:
%somehash = ();
This declaration is outside of any subroutines. VirtualHosts then call
App-load(name, libdir) to fille $somehash{$name} with a hashref of
page objects. All logging led me to believe that this variable was
being properly populated, but when that variable was accessed (via
getApp($name)), %somehash was undef.
Silly mistakes aside, I was basically trying to create a 'global'
variable that was populated by a method call _after_ it was
require()ed. The problem comes from the module being loaded _twice_.
The second time, %somehash = () sets things back to undef, but
loadApp() is not called again.
My motive for questioning the list was to find out if Apache's 'will
this survive a SIGHUP' pass caused this behavior, or if it was
something else I was missing.
I re-attacked this problem by adding a caller() check in App, and it
proved to me that App was indeed being loaded twice. Once by my
startup.pl (use App ();), and _again_ by an eval. caller() couldn't
point me to the spot of code that was doing this, other than telling me
it was a 'require App;'. I started flipping switches and localized it
to PerlFreshRestart being on. When I turn it off, the eval() happens
_before_ my startup.pl use() and subsequence call to App-load().
So this long-winded explanation is for the archives, and also to get an
idea as to why this happens. Thanks! :)
Cory 'G' Watson
Cory 'G' Watson
http://www.loggerithim.org
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Odd Reload Behavior
I've recently written some code that behaves in a way I don't understand. It's basically a Handler that works for more than one VirtualHost. For each VirtualHost that uses the Handler, a call is made to App-loadPages(). It crawls an accompanying lib directory and loads the pages into a hashref, which is then stored in a global hash inside App. Later, during requests, the Handler calls App-getPages(key), where key is a unique name for each virtual host. This _should_ return a hashref full of page objects, but it returns undef. Since the App module is pre-loaded (in startup.pl), and loadPages() fills the hash, shouldn't the Handler's calls to getPages(key) work? I know it can, because I had it working a couple weeks ago, but something has broken it. It looks as though this works during the first 'load' that Apache does, which I'm assuming is the phase that checks for errors. The second phase seems to cause my global hash to get undef'ed, even though the loadPages() method works properly. I can divulge more code if necessary, but perhaps someone can clue me into why this happens. Cory 'G' Watson http://www.loggerithim.org -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Odd Reload Behavior
On Friday, August 15, 2003, at 12:43 PM, Ged Haywood wrote:
I'm not entirely convinced of the explanation, but have you tried
testing the value of $Apache::Server::ReStarting in the code that
fills the hash? It's in the Guide.
I'm not convinced of it either. :)
This code _would_ run twice, so I can protect it using the variable you
specified. I didn't know it existed. List messages seem to say that
this shouldn't be used?
Your message was a bit cavalier about what's a hash and what's a
hashref, are you sure you aren't just missing a dereference somewhere?
Have you got 'use strict' and warnings on.
It's a difficult concept to relay without pasting a bunch of code.
-- App.pm:
package App;
my %pageobjs;
sub loadApp {
my $self = shift();
my $name = shift();
my $libdir = shift();
my %pages;
opendir(LIBDIR, $libdir);
while(there are files to check) {
# blah, if the file is a .pm, require and instantiate it into
$page
$pages{$pageObjectName} = $page;
closedir(LOBDIR);
$pageobjs{$name} = \%pages;
}
sub getPages {
my $self = shift();
my $name = shift();
return $pageobjs{$name};
}
-- startup.pl:
use App;
Sooo, using the above code, the VHost uses:
PerlVar app blah
Perl
App-loadApp(blah, /usr/local/blah/lib);
/Perl
And, inside the Handler:
my $app = $r-dir_config(app);
my $hashRefOfPageObjs = App-getPages($app);
And $hashRefOfPageObjs is always undef;
Ignore syntax errors and lack of declarations, as I just threw that
together from memory into the ol' MUA here. Does that make more sense?
I believe I had this working at one point, but something has caused it
go south. The double load I see (which you explained with your
Restarting tip) was suspect only because if I put code into App which
Data::Dumper's the hash, there is something in it, but it disappears
between the first load and the first request. It looks like Perl
sections are executed twice, but this shouldn't cause the variable to
go undefined.
Cory 'G' Watson
http://www.loggerithim.org
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Optimising cache performance
On Friday, March 7, 2003, at 12:45 PM, Perrin Harkins wrote: You seem to be taking a lot of care to ensure that everything always has the latest version of the data. If you can handle slightly out-of-date data, I would suggest that you simply keep objects in the local cache with a time-to-live (which Cache::Mmap or Cache::FileCache can do for you) and just look at the local version until it expires. You would end up building the objects once per server, but that isn't so bad. I'm not sure if my way would fit in with your objects Clinton, but I have some code in the commit() method of all my objects which, when it is called, removes any cached copies of the object. That's how I stay up to date. Cory 'G' Watson http://gcdb.spleck.net
Re: Optimising cache performance
On Friday, March 7, 2003, at 02:20 PM, Perrin Harkins wrote: Cory 'G' Watson wrote: I'm not sure if my way would fit in with your objects Clinton, but I have some code in the commit() method of all my objects which, when it is called, removes any cached copies of the object. That's how I stay up to date. Why wouldn't it simply update the version in the cache when you commit? Also, do you have a way of synchronizing changes across multiple machines? I suppose it could, but I use it as a poor man's cache cleaning. I suppose it would boost performance to do what you suggest. I'll just implement a cache cleaner elsewhere. I only run on one machine, so I don't do any synchronization. I hope to have that problem some day ;) Cory 'G' Watson http://gcdb.spleck.net
ANNOUNCE: Loggerithim 6.3.1
Hello again, Loggerithim 6.3.1 is now available, ChangeLog follows: - 6.3.1 * Installer fixes * Unit tests * Fixes from the removal of old db columns * Disable debugging in the agent by default About Loggerithim: Loggerithim is a monitoring package that allows you to monitor your systems, proactively spot problems, perform post-mortems, throw alerts when bad (or good) things happen, and automate routine tasks. http://loggerithim.sourceforge.net As always, please report any problems to the appropriate mailing list (see the website). Upgrading users can consult Appendix C of the documentation. Cory 'G' Watson http://gcdb.spleck.net
Re: Table/row locking with Apache::Session::Mysql /Apache::Session::Flex
On Tuesday, February 25, 2003, at 11:55 AM, md wrote: We're using Apache::Session::MySQL (Apache::Session 1.54) and occassionaly see long lock times. I had a similar problem a few months ago with Apache::Session::Postgres. I occasionally had Apache processes hang, and a quick ps aux shows a stalled query on the sessions table. I ended up dropping it for Apache::Session::File. I'm looking at Apache::Session::Flex and setting Lock='Null'...however, I get the impression from an old email (see below) that Flex is for debugging only. I've not seen the problems since I switched to Apache::Session::File, but I would much prefer using the Postgres module, as it complicates my user's installation. Could the MySQL and Pg implementations have the same problem? Cory 'G' Watson http://gcdb.spleck.net
ANNOUNCE: Loggerithim 6.3.0
Hello again, Loggerithim 6.3.0 is now available, ChangeLog follows: - 6.3.0 * Use page that returns an image/png, rather than writing one to the filesystem * Added filesystem code to the OS X agent, bringing it near completion. * Use the IP of a host, then fallback to supplied hostname when metrics are received. * Implement debugging, via configuration file. Displays lots of verbose output in the page footer if enabled. * Remove 'types' column from users table in preparation for a future permissions implementation. * Cleaned up some debugging stuff. About Loggerithim: Loggerithim is a monitoring package that allows you to monitor your systems, proactively spot problems, perform post-mortems, throw alerts when bad (or good) things happen, and automate routine tasks. As always, please report any problems to the appropriate mailing list (see the website). Upgrading users can consult Appendix C of the documentation. Cory 'G' Watson http://gcdb.spleck.net
Re: Help installing mod_perl 1.27 and apache 1.3.27. newbie question.
On Thursday, February 20, 2003, at 08:13 AM, Charlie Smith wrote: I get errors on installing mod_perl/Apache 1.3.27, under the root account when running perl Makefile.PL. I'm running perl 5.8 on solaris. gcc 2.95. # # # perl Makefile.PL Configure mod_perl with ../apache_1.3.27/src ? [y] Shall I build httpd in ../apache_1.3.27/src for you? [y] sh: make: not found It can't find the 'make' program. You either need to install make, or, if it is isntalled, make sure it's in your $PATH. Cory 'G' Watson http://gcdb.spleck.net
ANNOUNCE: Loggerithim 6.2.2
Howdy, http://loggerithim.sourceforge.net Loggerithim 6.2.2 is available, ChangeLog follows: - 6.2.2 Fix a typo in the creation of the attributes table Add support for 'ce' interfaces in Solaris About Loggerithim: Loggerithim is a monitoring package that allows you to monitor your systems, proactively spot problems, perform post-mortems, throw alerts when bad (or good) things happen, and automate routine tasks. As always, please report any problems to the appropriate mailing list (see the website). Upgrading users can consult Appendix C of the documentation. Cory 'G' Watson http://gcdb.spleck.net
ANNOUNCE: Loggerithim 6.2.1
Hello again, http://loggerithim.sourceforge.net Loggerithim 6.2.1 is now available, abbreviated ChangeLog follows (I deleted the original by accident!): - 6.2.1 Don't draw data in filled mode when there is none to draw Take the 'thresholds' field out of the smeeplets table and objects Added LastSampled Smeeplet Rewritten threshold handling, fixes numerous bugs Set CPU attribute to use filled graph and max value of 100 XHTML 1.1 Compliance Significantly improved installer About Loggerithim: Loggerithim is a monitoring package that allows you to monitor your systems, proactively spot problems, perform post-mortems, throw alerts when bad (or good) things happen, and automate routine tasks. As always, please report any problems to the appropriate mailing list (see the website). Upgrading users can consult Appendix C of the documentation. Cory 'G' Watson http://gcdb.spleck.net
ANNOUNCE: Loggerithim 6.2.0
http://loggerithim.sourceforge.net Loggerithim is monitoring package for Linux and Solaris (with early support for OS X and Windows). It allows you to collect metrics from your hosts and analyze them with graphs and whatnot. You can also set thresholds for proactively spotting problems. Modules can be written to supplement the stock data collection. Changes: - Rewritten Chart code allows for fancier graphs, the first result is filled graphs. - Profile support, for grouping host attributes into logical groups. This makes it easier to monitor things that aren't UNIX boxes. - XHTML 1.1 valid (for the most part) - Interface tweaks to make things easier to understand This is my second announcement to the modperl list. I got a nibble of feedback, but nothing big. I welcome opinions or criticism, as I don't know of very many installs outside the walls of my work. Thanks! Cory 'G' Watson http://gcdb.spleck.net
ANNOUNCE: Loggerithim 6.1.4
http://loggerithim.sourceforge.net Loggerithim is monitoring package for Linux and Solaris (with early support for OS X and Win32). It allows you to collect metrics from your hosts and analyze them with graphs and whatnot. You can also set thresholds for proactively spotting problems. Modules can be written to supplement the stock data collection. Loggerithim is mod_perl (obviously) and PostgreSQL. Agents written in C collect data and send it to the box that runs Loggerithim. This is the first time I've announced Loggerithim somewhere other than Freshmeat. I'd greatly appreciate feedback from the mod_perl crowd. I'm impressed with the work of others on the list and I welcome your opinions. Expect rough edges and broken pieces as very few people have run it outside of my office. Mailing lists are available for anyone interested, see the website. Thanks! Cory 'G' Watson http://gcdb.spleck.net
Re: [OT] Perl vs. PHP..... but where is mod_perl?
Randal L. Schwartz wrote: Dzuy What do you expect from (PHP) amateurs? Apparently Perl is too Dzuy complicated for them to comprehend, Dzuy never mind mod_perl. And according to my thread at use.perl http://use.perl.org/~merlyn/journal/8445, the article just got pulled! The article says PHP is syntactically similar to C++. What PHP are they using? I picked up PHP in no time because it was nearly indentical to Perl. Sure, it's similar to C and C++, but, uhmm, $variable? Also mentions Perl has had OO bolted on. How do they view PHP's OO? I'm not bashing PHP, quite the contrary. But damn, that's just an ignorant article. I do wonder what sparked them pulling it out. -- Cory 'G' Watson
Re: [OT] Perl vs. PHP..... but where is mod_perl?
Randal L. Schwartz wrote: What confuses me is how anyone with a *programming* background admires PHP over Perl, or can say that Perl doesn't scale or PHP is better for large web sites. Obviously, they're comparing Perl-CGI with PHP, not mod_perl/$templating_system with PHP, which would be a much fairer comparison. I absolutely agree. I learned PHP _before_ I learned mod_perl and _after_ I learned Perl/CGI. I actually didn't even know mod_perl existed when I learned PHP. I have a feeling many people are in the same boat. Anyone who has a sufficient itch will learn that mod_perl is a fantastic back scratcher. I am generally able to show people the huge difference by explaining the implementation of authentication and authorization in an application. Where in PHP I had to include an seperate .php file which verified my sessions, in mod_perl I simple whip up an AccessHandler or Authorization handler that quietly protects my app's innards. But for folks who are just throwing a page up, and have PHP services available with an ISP/host, I can understand it's use. -- Cory 'G' Watson
Re: IPC::MM and mod_perl
I'm not sure about IPC::MM, but IPC::ShareLite (the one I use) lets you specify permissions and whatnot when you create the shared memory segment. Perhaps that module will work better for you. IPC::Shareable is also a good one. On Thursday 25 July 2002 07:38 pm, Marc Kelly wrote: This may be more of an Apache question, but I saw a thread in the mod_perl archives on caching methods that is relevant. I'd like to use IPC::MM to store data in shared memory across child processes, but I've run into permissions problems. I'm assuming this is because I'm creating the cache in startup.pl which is run by root, and trying to store data in a child process that is run as user apache. If I create the cache in a child process, I can write to it, but lose the ability to use it in other child processes. The IPC::MM perldoc mentions file permissions, but I think that's for a file-based cache, which doesn't apply here. I could be wrong on that and just setting the permissions incorrectly. I haven't found a lot of documentation about using this library, so maybe this isn't the proper way for it to be used. I'm on Linux (RH 7.3/2.4.18-3) and apache 1.3.22. Thanks, mk -- Cory 'G' Watson Hack, lest ye rust.
