Apache::VMonitor not showing requests (might be Apache::Scoreboard problem)
Hi list,
I've got some problems with getting Apache::VMonitor showing the
requests, everything but client ip and requests shows.
when i call server/scoreboard do i get a file, and 'strings
scoreboard|grep -A 1 myip' shows my ip and request (can't find the pid
though) so the info should be there. I've added :
'REQ='.$rec-{request}.''; #line 373 in Apache::VMonitor
and when i call server/sys-monitor do i get 'REQ=' foreach row. So it
tries to print but it's all empty.
I guess this is some silly conf thingy i've missed out. I have it
running fine on another system and i can't see the diff in
configuration.
here's a snippet of httpd.conf:
# httpd.conf
PerlFreshRestart On
Perlrequire /usr/local/apache/conf/startup.pl
PerlModule Apache::Scoreboard
Location /perl-status
SetHandler perl-script
PerlHandler Apache::Status
order deny,allow
deny from all
allow fromlocalhost
/Location
Location /sys-monitor
SetHandler perl-script
PerlHandler Apache::VMonitor
order deny,allow
deny from all
allow from localhost
/Location
Location /scoreboard
SetHandler perl-script
PerlHandler Apache::Scoreboard::send
order deny,allow
deny from all
allow from localhost
/Location
# END
and here's the part from startup.pl with Apache::VMonitor:
use Apache::VMonitor();
$Apache::VMonitor::Config{BLINKING} = 1;
$Apache::VMonitor::Config{REFRESH} = 0;
$Apache::VMonitor::Config{VERBOSE} = 0;
$Apache::VMonitor::Config{SYSTEM} = 1;
$Apache::VMonitor::Config{APACHE} = 1;
$Apache::VMonitor::Config{PROCS}= 1;
$Apache::VMonitor::Config{MOUNT}= 1;
$Apache::VMonitor::Config{FS_USAGE} = 1;
$Apache::VMonitor::Config{SORT_BY} = 'size';
$Apache::VMonitor::PROC_REGEX = join |, qw(httpd mysql);
$Apache::VMonitor::Config{PROC_REGEX} = join |, qw(httpd mysql);
#END
And here's my system:
Embedded Perl version v5.6.0 for Apache/1.3.23 (Unix) mod_perl/1.26
$Apache::VMonitor::VERSION = '0.6';
Apache::Scoreboard version: $VERSION = '0.10';
So is there anything obivous I've missed out?
/Jon
Apache modperl on OS/2 - realistic ?
Is Apache modperl on OS/2 a realistic proposition ? Could anybody point me to any literature ? thanks. Rod === Corporate confidentiality statement goes here.
Re: PDF generation
Mike808 wrote: Don't know if you can run a JServ+mod_perl or JPerl hybrid, though. You can, but it would be the biggest memory hog every created, since it would be running a JVM in addition to the Perl interpreters. - Perrin
Re: PDF generation
On April 3, 2002 12:43 pm, Bill McCabe wrote: I have a large number of mod_perl modules that connect to various databases and generate workflow performance reports for my organization. I give the users 3 output options: HTML, Excel (Spreadsheet::WriteExcel), and PDF. For PDF output I've been using PDF::Create, which has been at version .01 since 1999. It has worked flawlessly for my purposes for a couple of years, but is very limited. In fine form-follows-function fashion, the end users would now like the PDF output gussied up with graphics, etc. Does anyone have any strong (positive or negative) recommendations for which module(s) I should migrate to? We've been using the Text::PDF modules here ourselves on several projects, all with great success. Is a bit low-level, though, which may not be quite what you're looking for. There's also a Text::PDF::API2 package on CPAN which takes the low-level stuff and presents a higher-level API to help you in building up your PDF documents. We needed something that'd give us ultimate low-level control over PDF entities so we went with Text::PDF ourselves, but both of them work quite well. -- Graham TerMarsch Howling Frog Internet Development, Inc. http://www.howlingfrog.com // - // DEC diagnostics would run on a dead whale. -- Mel Ferentz // -
Re: Apache::VMonitor not showing requests (might be Apache::Scoreboard problem)
Maybe adding this to your httpd.conf will help: ExtendedStatus On ?
RE: PDF generation
In reference to PDF::Create... Has anyone found any good documentation behind the module... I would like to print the results of a query to PDF and I not exactly sure whether I can use an array or a concatenate the results in a string. Allen -Original Message- From: Perrin Harkins [mailto:[EMAIL PROTECTED]] Sent: Thursday, April 04, 2002 9:39 AM To: Mike808 Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: PDF generation Mike808 wrote: Don't know if you can run a JServ+mod_perl or JPerl hybrid, though. You can, but it would be the biggest memory hog every created, since it would be running a JVM in addition to the Perl interpreters. - Perrin This message may contain proprietary or confidential company information. Any unauthorized use or disclosure is prohibited.
Open3
Folks, I have asked this question before, and received answers that have helped me in quest. However, my problem persists. So I would like to direct this question to those who have used gpg, and open3. I am having trouble writing to stdin when an apache thread calls open3. However, the same code written as a test script runs fine. I am using the --passphrase-fd 0 option which would instruct gpg to expect the passphrase from stdin rather than keyboard. As I mentioned above, the problem arises when an apache thread tries to execute my code. I know that under perl 5.6 it is necessary to untie STDIN,... (thanks Don Hayward), but I am using perl 5.005_03 built for irix ( Apache/1.3.12 Ben-SSL/1.39 (Unix) mod_perl/1.22). What is happening that I am missing? Thanks in advance -r
RE: PDF generation
On 4/4/02 at 1:07 PM, [EMAIL PROTECTED] (Wilson, Allen) wrote: In reference to PDF::Create... Has anyone found any good documentation behind the module... I would like to print the results of a query to PDF and I not exactly sure whether I can use an array or a concatenate the results in a string. Allen AFAIK, the only docs are what comes with the distribution. For tabluar reports, I retrieve all my results as array's which get fed to a function that calculates x,y pixel offsets and print each item to its position. If you want to make a string out of each row, you'll have to use a fixed width font and calculate the needed spaces to pad each column and you'll still need to track vertical pixel position for each row, so it didn't seem to be much less work to me to go that route. Anyway, as I pointed out in my initial question, though PDF::Create has worked flawlessly for me for the last two years, it definitely seems to have been orphaned by its creator. If you're just getting started with perl-PDF generation, why not choose one of those recommended in this thread? My inclination would be use Matt Sergeant's PDFlib which seems well designed, but I have a (probably unjustifiable) knee-jerk reaction against having to license products. So, I'll give PDF::API2 a whack. Bill
Problem with DBM concurrent access
Hi there, I have a quick and possibly trivial question that has bothered me for quite a while. I'm using a DBM as a repository. The DBM is constantly written to by only one process (the 'writer') that opens it RW. At the same time, many process (the 'reader') access it *read only*. I experience the fact that the 'readers' never get the last values written by the 'writer'. I suspect a problem of flush for the 'writer', and a problem of synchronisation for the 'reader'. So my question narrows down to : How to flush on disk the cache of a tied DBM (DB_File) structure in a way that any concurrent process accessing it in *read only* mode would automatically get the new values as soon as they are published (synchronisation) Thanks in advance. Franck Essential Software - Ingénierie Informatique Solutions Linux Open Source en Polynésie française http://www.esoft.pf/ Tél: (689) 56 23 95
Re: Problem with DBM concurrent access
Franck PORCHER wrote: So my question narrows down to : How to flush on disk the cache of a tied DBM (DB_File) structure in a way that any concurrent process accessing it in *read only* mode would automatically get the new values as soon as they are published (synchronisation) You have to tie and untie on each request. There's some discussion of this in the Guide. As an alternative, you could look at using BerkeleyDB, or MLDBM::Sync (which does the tie/untie for you). - Perrin
RE: Problem with DBM concurrent access
So my question narrows down to : How to flush on disk the cache of a tied DBM (DB_File) structure in a way that any concurrent process accessing it in *read only* mode would automatically get the new values as soon as they are published (synchronisation) Isn't that just as simple as tied(%dbm_array)-sync(); ? HTH! L8r, Rob
Access right on files from CGI script
Hellogurus,I am notivice on Apache configuration.I wrote a CGI program, which will displaysome system status on the client PC's browser window.This CGI program will execute a couple of system commandunder /sbin with reading some system status from /proc.I have no problem to access or execute any file or binary under /www/cgi-binbut I have an access problem to other system directories like /sbin or/proc.I followed the apache configuration document and I modified directory andcreated .htaccess file under /sbin but it did not help. How do I allow thosefiles accessiblefrom the CGI script? Please help me out.Thanks in advance,Bo
Re: Problem with DBM concurrent access
Rob Bloodgood wrote: So my question narrows down to : How to flush on disk the cache of a tied DBM (DB_File) structure in a way that any concurrent process accessing it in *read only* mode would automatically get the new values as soon as they are published (synchronisation) Isn't that just as simple as tied(%dbm_array)-sync(); I believe that's not enough, because the reader may read data during the write, resulting in corrupted data read. You have to add locking. see the DBM chapter in the guide. -- _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: [mod_perl] Restarting after a module changes when you're not able to restart
Hi Elizabeth, Apache::Reload or Apache::StatINC can reload modules for you without needing to restart the server. Your provider would need to have one of these installed and set up in the httpd.conf. If you get a choice in which one you use, Apache::Reload is much more configurable so you have more control over what gets reloaded when. Apache::StatINC will simply reload any module as soon as it's changed. more details: http://perl.apache.org/guide/porting.html#Reloading_Modules_and_Required_F --Carolyn On Thu, Apr 04, 2002 at 10:20:37PM -0600, Elizabeth Barham wrote: Hi, I have been writing scripts on a local machine. I noticed that mod_perl can tell when I change a CGI script, but if that script accesses a module or module that changes, it often times does not notice this. So, when I update the module files I restart apache. This has worked fine for my local machine, but the day is drawing near in which I may be installing this onto a web-host provider running mod_perl. If this happens and there is an upgrade or a bug-fix in a module, how does one deal with it? Does mod_perl garbage collect the compiled code after it has not been accessed in a while? Thank you, Elizabeth
Re: Problem with DBM concurrent access
Stas Bekman wrote:
tied(%dbm_array)-sync();
I believe that's not enough, because the reader may read data during the
write, resulting in corrupted data read. You have to add locking. see
the DBM chapter in the guide.
You might add MLDBM::Sync to the docs, which easily adds locking
to MLDBM. MLDBM is a front end to store complex data structures
http://www.perl.com/CPAN-local/modules/by-module/MLDBM/CHAMAS/MLDBM-Sync-0.25.readme
What's nice about MLDBM is you can easily swap in out various dbms
like SDBM_File, DB_File, GDBM_File, etc. More recently it even
supports Tie::TextDir too, which provides key per file type storage
which is good when you have a fast file system big data you want
to store.
SYNOPSIS
use MLDBM::Sync; # this gets the default, SDBM_File
use MLDBM qw(DB_File Storable);# use Storable for serializing
use MLDBM qw(MLDBM::Sync::SDBM_File); # use extended SDBM_File, handles values
1024 bytes
use Fcntl qw(:DEFAULT);# import symbols O_CREAT O_RDWR for use
with DBMs
# NORMAL PROTECTED read/write with implicit locks per i/o request
my $sync_dbm_obj = tie %cache, 'MLDBM::Sync' [..other DBM args..] or die $!;
$cache{} = ;
my $value = $cache{};
...
DESCRIPTION
This module wraps around the MLDBM interface, by handling concurrent
access to MLDBM databases with file locking, and flushes i/o explicity
per lock/unlock. The new [Read]Lock()/UnLock() API can be used to
serialize requests logically and improve performance for bundled reads
writes.
Here's some benchmarks on my 2.4.x linux box dual PIII 450 with a couple
7200 RPM IDE drives raid-1 ext3 fs mounted default async.
MLDBM-Sync-0.25]# perl bench/bench_sync.pl
NUMBER OF PROCESSES IN TEST: 4
=== INSERT OF 50 BYTE RECORDS ===
Time for 100 writes + 100 reads for SDBM_File 0.17 seconds
12288 bytes
Time for 100 writes + 100 reads for MLDBM::Sync::SDBM_File 0.20 seconds
12288 bytes
Time for 100 writes + 100 reads for GDBM_File 1.06 seconds
18066 bytes
Time for 100 writes + 100 reads for DB_File0.63 seconds
12288 bytes
Time for 100 writes + 100 reads for Tie::TextDir .04 0.38 seconds
13192 bytes
=== INSERT OF 500 BYTE RECORDS ===
(skipping test for SDBM_File 100 byte limit)
Time for 100 writes + 100 reads for MLDBM::Sync::SDBM_File 0.58 seconds
261120 bytes
Time for 100 writes + 100 reads for GDBM_File 1.09 seconds
63472 bytes
Time for 100 writes + 100 reads for DB_File0.64 seconds
98304 bytes
Time for 100 writes + 100 reads for Tie::TextDir .04 0.33 seconds
58192 bytes
=== INSERT OF 5000 BYTE RECORDS ===
(skipping test for SDBM_File 100 byte limit)
Time for 100 writes + 100 reads for MLDBM::Sync::SDBM_File 1.37 seconds
4128768 bytes
Time for 100 writes + 100 reads for GDBM_File 1.13 seconds
832400 bytes
Time for 100 writes + 100 reads for DB_File1.08 seconds
831488 bytes
Time for 100 writes + 100 reads for Tie::TextDir .04 0.52 seconds
508192 bytes
=== INSERT OF 2 BYTE RECORDS ===
(skipping test for SDBM_File 100 byte limit)
(skipping test for MLDBM::Sync db size 1M)
Time for 100 writes + 100 reads for GDBM_File 1.76 seconds
2063912 bytes
Time for 100 writes + 100 reads for DB_File1.78 seconds
2060288 bytes
Time for 100 writes + 100 reads for Tie::TextDir .04 1.27 seconds
2008192 bytes
=== INSERT OF 5 BYTE RECORDS ===
(skipping test for SDBM_File 100 byte limit)
(skipping test for MLDBM::Sync db size 1M)
Time for 100 writes + 100 reads for GDBM_File 3.52 seconds
5337944 bytes
Time for 100 writes + 100 reads for DB_File3.37 seconds
5337088 bytes
Time for 100 writes + 100 reads for Tie::TextDir .04 2.80 seconds
5008192 bytes
--Josh
_
Joshua Chamas Chamas Enterprises Inc.
NodeWorks Founder Huntington Beach, CA USA
http://www.nodeworks.com1-714-625-4051
Re: Problem with DBM concurrent access
Isn't that just as simple as tied(%dbm_array)-sync(); I believe that's not enough, because the reader may read data during the write, resulting in corrupted data read. Not only that, there's also the issue with at least some dbm implementations that they cache part of the file in memory and will not pick up changed data unless you untie and re-tie. I remember a good discussion about this on the list a year or two back. - Perrin
Re: Access right on files from CGI script
At 5:39 PM -0800 4/4/02, bo wrote: How do I allow those files accessible from the CGI script? The problem has nothing to do with Apache. The user that the Apache process is running as does not have access to those files. You need to either open up the permissions on /sbin to more users (probably not a good idea), or change who Apache runs as (not really a terribly good idea either), or make some custom commands that do what you want, but can only be run by Apache, and only with arguments that you have very carefully specified (rather difficult). Or you could go with security-by-obscurity model and make private versions of the commands that can only be read and run by the Apache user. -- Kee Hinckley - Somewhere.Com, LLC http://consulting.somewhere.com/ [EMAIL PROTECTED] I'm not sure which upsets me more: that people are so unwilling to accept responsibility for their own actions, or that they are so eager to regulate everyone else's.
[mod_perl] Restarting after a module changes when you're not able to restart
Hi, I have been writing scripts on a local machine. I noticed that mod_perl can tell when I change a CGI script, but if that script accesses a module or module that changes, it often times does not notice this. So, when I update the module files I restart apache. This has worked fine for my local machine, but the day is drawing near in which I may be installing this onto a web-host provider running mod_perl. If this happens and there is an upgrade or a bug-fix in a module, how does one deal with it? Does mod_perl garbage collect the compiled code after it has not been accessed in a while? Thank you, Elizabeth
Re: Access right on files from CGI script
or of course, you could use the 'group's feature and put the user apache runs as in the right groups and give that group the permissions to run the files you want in /sbin... On Fri, 2002-04-05 at 14:12, Kee Hinckley wrote: At 5:39 PM -0800 4/4/02, bo wrote: How do I allow those files accessible from the CGI script? The problem has nothing to do with Apache. The user that the Apache process is running as does not have access to those files. You need to either open up the permissions on /sbin to more users (probably not a good idea), or change who Apache runs as (not really a terribly good idea either), or make some custom commands that do what you want, but can only be run by Apache, and only with arguments that you have very carefully specified (rather difficult). Or you could go with security-by-obscurity model and make private versions of the commands that can only be read and run by the Apache user. -- Kee Hinckley - Somewhere.Com, LLC http://consulting.somewhere.com/ [EMAIL PROTECTED] I'm not sure which upsets me more: that people are so unwilling to accept responsibility for their own actions, or that they are so eager to regulate everyone else's.
