[ANNOUNCE] mod_perl-1.28
The URL
http://perl.apache.org/dist/mod_perl-1.28.tar.gz
has entered CPAN as
file: $CPAN/authors/id/G/GO/GOZER/mod_perl-1.28.tar.gz
size: 375986 bytes
md5: 889ad726a6d7c2fe03b2b1b93662f515
Changes since 1.27:
Apache::FakeRequest now isa Apache so code that is carefull about
$r and checks that $r-isa('Apache') will not fail [David Wheeler
[EMAIL PROTECTED]
Add Mac OS X support to Apache::SizeLimit [David Wheeler
[EMAIL PROTECTED]]
Add Win32 support to Apache::SizeLimit [Matt Phillips
[EMAIL PROTECTED] and Mohamed Hendawi [EMAIL PROTECTED]]
Change Apache::SizeLimit to not push a cleanup handler if already in
the cleanup handler phase, and adjust docs to show that cleanup
handler is the preferred phase to use [Perrin Harkins
[EMAIL PROTECTED]]
Rename Apache::test to Apache::testold because Apache::test on
case-insensitive systems will collide with Apache::Test which
supercedes Apache::test. So if you want to keep on using Apache::test,
either bundle it with your project (putting it under inc/ or t/ so it
won't be installed) or require mod_perl 1.28 and use Apache::testold
instead. Of course the best route is to port your test suite to use
a much better Apache::Test which work with mod_perl 1.0 and 2.0.
[Philippe M. Chiasson, Stas Bekman]
Tweak mod_perl.h to defined _INCLUDE_APACHE_FIRST only after apache
headers were included [Stas Bekman]
avoid various warnings under src/modules/perl/:
- declare bufsiz to be STRLEN in Apache.xs, and add
STRLEN to Apache/typemap
- add I32 typecast in Constants.xs
- avoid use of unregistered local variables for Win32
in mod_perl.c and perl_config.c
- s/I32/U8/ in mod_perl.h, perl_config.c, and perl_util.c
- declare i and http_code to be STRLEN in perl_util.c
[Stas Bekman, Randy Kobes]
don't use $r variable in Apache::PerlRun::compile(), so the script
won't use use inherited $r by mistake [Stas Bekman]
define PERL_DIRECTIVE_HANDLERS so that ModuleConfig.c gets
generated when building on Win32 within Visual Studio
[John Petrakis [EMAIL PROTECTED]]
enable PERL_SECTIONS for Win32 [Dirk Maetens [EMAIL PROTECTED]]
use touch() from ExtUtils::Command, rather than a system touch(),
for the benefit of platforms without touch(). [Randy Kobes
[EMAIL PROTECTED]]
can't let the default typemap rule to convert sv into char* in
unescape_url, since it doesn't handle correctly undefs (returns an
unallocated string, which then causes a segfault in
ap_unescape_url. use SvPV_force, instead, which does the right
thing. [Stas Bekman]
Make sure to start perl, if it's not running, before processing Perl*
directives, with threaded perl and PERL_STACKED_HANDLERS=0 [Stas
Bekman]
Add Apache::Module to Bundle::Apache [Stas Bekman]
use $Config{'installstyle'} instead of hardcoded 'lib', to handle
Makefile.PL's PREFIX option correctly [Philippe M. Chiasson
[EMAIL PROTECTED]]
prevent segfaults in mod_perl_mark_where() when a sub can't get
resolved [Gerald Richter [EMAIL PROTECTED]]
Apache::Status: Need to load B::Terse/TerseSize if it wasn't loaded
yet in that child before using it. [Dan Sully
[EMAIL PROTECTED]]
document the server_root_relative() method [Stas Bekman
[EMAIL PROTECTED]]
eliminate warnings when flushing functions with empty () prototypes in
Apache::PerlRun::flush_namespace [Yair Lenga [EMAIL PROTECTED]]
fix Apache::Status to not use :: in filenames, which is not allowed on
certain OSs [DH [EMAIL PROTECTED]]
various cygwin fixes [Per Einar Ellefsen [EMAIL PROTECTED]]
fix to compile with 5.8.0 on win32 [Randy Kobes
[EMAIL PROTECTED]]
Document the possible misuses of the Apache::Constant constants
[Per Einar Ellefsen [EMAIL PROTECTED]]
Patches since 1.27 can be reviewed here:
http://www.apache.org/~gozer/mp1/1.27-dev/
--
--
Philippe M. Chiasson /gozer\@(cpan|ectoplasm)\.org/ 88C3A5A5 (122FF51B/C634E37B)
http://gozer.ectoplasm.org/F9BF E0C2 480E 7680 1AE5 3631 CB32 A107 88C3 A5A5
Q: It is impossible to make anything foolproof because fools are so ingenious.
perl -e'$$=\${gozer};{$_=unpack(P7,pack(L,$$));/^JAm_pH\n$/print||$$++redo}'
signature.asc
Description: This is a digitally signed message part
Re: [ANNOUNCE] mod_perl-1.28
Hi Philippe, Philippe M. Chiasson wrote: The URL http://perl.apache.org/dist/mod_perl-1.28.tar.gz has entered CPAN I still get the same test failures that I reported before when RC2 was announced: modules/request...FAILED tests 3-8 Failed 6/10 tests, 40.00% okay Setup: Windows XP, Perl 5.8.0, Apache 1.3.27, Apache-Test 1.03, libapreq-1.2 (built/installed *after* mod_perl 1.28). I used to have All tests successful under mp-1.27. (I note that Apache::Reload didn't make it in either; I thought the plan was to put a backport of the version from mp2 into it?) Steve
Is statically-compiled mod_perl better?
What is the preferred method of compiling mod_perl - static or dynamic? I have read that *static* linking is likely to load and execute faster, but may be wasteful of resources if there are multiple proceses each with its own copy of the common code. It therefore seems likely that a statically compiled mod_perl would be faster, provided that a large number of httpd's are not being run at the same time. Is this correct? It seems that at present it is not possible to build mod_perl 2.0 statically. It can only be built dynamically and loaded using LoadModule in httpd.conf. This seems strange if the preferred method of building is static. Thanks Colin __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com
Re: If (!$one_thing) {$other;}
Hi there, On Wed, 2 Jul 2003, Dennis Stout wrote: This also means I can write a small subroutine to eval a form that's been posted, and given the authentication passes, add code to the thing while it's running, AND save the code to the DB so it'll be around for reboots. Wouldn't that just be awesome? Can I urge a little caution? 73, Ged.
Re: Is statically-compiled mod_perl better?
Hi there, On Thu, 3 Jul 2003, ColinB wrote: What is the preferred method of compiling mod_perl - static or dynamic? Static. (But that's just my opinion after years of experience and watching people running into trouble with DSO mod_perl on this List. :) I have read that *static* linking is likely to load and execute faster, but may be wasteful of resources if there are multiple proceses each with its own copy of the common code. In normal circumstances the speed of loading is unlikely to be an issue. If you're using mod_perl 1.x on Linux/Unix/whatever then unless you're using 'httpd -X' or a very strange configuration there will be multiple processes. A recent post by Randal seemed to indicate the memory saved by using a DSO mod_perl wasn't as large as one might think - check the archives. It therefore seems likely that a statically compiled mod_perl would be faster, provided that a large number of httpd's are not being run at the same time. Is this correct? There are many factors to consider, but the speed difference between static and DSO isn't often talked about here so you can draw your own conclusions. Check out the tuning section of the Guide, the archives. It seems that at present it is not possible to build mod_perl 2.0 statically. It can only be built dynamically and loaded using LoadModule in httpd.conf. This seems strange if the preferred method of building is static. True. That's because it's still in development. Check the archives... 73, Ged.
Re: Is statically-compiled mod_perl better?
Ged == Ged Haywood [EMAIL PROTECTED] writes: Ged A recent post by Randal seemed to indicate the memory saved Ged by using a DSO mod_perl wasn't as large as one might think - check the Ged archives. And I've confirmed that observation at least on Solaris and OpenBSD. You can build a static mod_perl-enabled binary. Just be sure to have: ClearModuleList AddModule mod_mime.c ... and add only the modules that you're using. Modules that don't get add-ed appear to take up no data space... just becoming part of the shared single binary that is being accessed. (You can get the list with 'httpd -l' and a bit of text massaging.) My front proxy processes are a mere 1.5 Meg right now, running basically mod_ssl, mod_rewrite, and mod_proxy, and it's the same binary as my backend mod_perl work processes, running about 10 to 15 Meg a piece. No more DSO. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 [EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
[ANNOUNCE] OpenInteract 1.99_01 (2.0 beta 2) released
The second beta of OpenInteract2 (1.99_01) has been released to CPAN and SourceForge. The release: includes many documentation updates, has a totally revamped logging system using log4perl, supports multiple content generators, introduces content filters and has a bunch of other features, fixes and improvements. A detailed changelog is online [1], as are the HTML-ified docs [2]. And if you can't wait for your CPAN mirror you can download it immediately.[3] Thanks, Chris [1] http://sourceforge.net/project/shownotes.php?group_id=16810release_id=169294 [2] http://openinteract.sourceforge.net/docs/oi2/ [3] http://prdownloads.sourceforge.net/openinteract/OpenInteract-1.99_01.tar.gz?download -- Chris Winters ([EMAIL PROTECTED]) Building enterprise-capable snack solutions since 1988.
Re: Is statically-compiled mod_perl better?
Thanks for the comments. I guess I'll just have to stick with the dynamically-linked mod_perl 2.0 for the time being. I'll keep checking the mod_perl 2.0 site pages and pick up a static-capable version when it becomes available. Colin __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com
Apache config problem .. please help
I made a simple mod_perl change to the config and when restarting Apache I got this error: (98)Address already in use: make_sock: could not bind to address 0.0.0.0:2250 no listening sockets available, shutting down /usr/local/apache/bin/apachectl: line 87: 16512 Segmentation fault $HTTPD $ARGV I then backed out the change and retried, got the same error. Any clues?
Re: Apache config problem .. please help
I made a simple mod_perl change to the config and when restarting Apache I got this error: (98)Address already in use: make_sock: could not bind to address 0.0.0.0:2250 no listening sockets available, shutting down /usr/local/apache/bin/apachectl: line 87: 16512 Segmentation fault $HTTPD $ARGV I then backed out the change and retried, got the same error. killall httpd then try it again :) Dennis
Re: Apache config problem .. please help
Hi there, On Thu, 3 Jul 2003, Dennis Stout wrote: I made a simple mod_perl change to the config and when restarting Apache I got this error: (98)Address already in use: make_sock: could not bind to address 0.0.0.0:2250 no listening sockets available, shutting down /usr/local/apache/bin/apachectl: line 87: 16512 Segmentation fault $HTTPD $ARGV I then backed out the change and retried, got the same error. killall httpd then try it again :) In other words there's an Apache still running when you're trying to start a second one which wants to listen on the same socket that the first Apache is already listening on. That isn't permitted. But you shouldn't be getting segmentation faults in that case so something else is probably wrong too. Did you build from source? Did you follow the instructions in the Guide? Linux? 1.3.27/1.27? DSO? Maybe you can post the information requested in the docs? 73, Ged.
Re: require'ing data files under mod_perl
On Mon, Jun 30, 2003 at 05:28:43PM -0400, Perrin Harkins wrote:
On Sat, 2003-06-28 at 15:08, Peter B. Ensch wrote:
Coding in plain CGI I've often require'd files containing
data in perl data-structures. The script may write to the
file (via Data::Dumper for example) allowing subsequent
invokations of the script to have access to the revised
data.
It would be simpler and faster to use MLDBM::Sync for this.
Not familiar w/ this module and it's not on our system; I'll
certainly look into it.
I was expecting this methodology to break under mod_perl
thinking that the require would only happen once (the
first time the script runs after server startup); however,
it seems to be working the way it always did.
Why is this? Am I missing something?
Can't tell without seeing some code. Your require'd files with not be
reloaded unless you are using Apache::Reload or Apache::StatINC to force
them.
I'm NOT using A::Reload or A::StatINC. My script appears to be
require'ing the data file on each user transaction, just like
under plain CGI.
I'm using CGI::Application and this part of the code happens inside
the cgiapp_init() method which I'm overriding:
our $USERS : unique = /path/to/users.dat;
sub cgiapp_init {
my $self = shift;
$self-param('users' = require ${\$USERS});
}
So, to reiterate, I may write to users.dat on one transaction
and read on another; the file contents is always up-to-date.
I still can't understand why this is because I did not think
it would be reloaded unless the server was restarted.
BTW - it doesn't have anything to do with the 'unique' our
attribute; same behavour with or without.
I'm new to apache and I'm not running in single-process mode;
this shouldn't have a bearing should it?
Thanks,
P
--
^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^
Peter Ensch,
[EMAIL PROTECTED] A-1140 (214) 480 2333
^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^
Re: Apache config problem .. please help
Ged Haywood wrote:
Hi there,
On Thu, 3 Jul 2003, Dennis Stout wrote:
I made a simple mod_perl change to the config and when restarting Apache
I got this error:
(98)Address already in use: make_sock: could not bind to address
0.0.0.0:2250
no listening sockets available, shutting down
/usr/local/apache/bin/apachectl: line 87: 16512 Segmentation fault
$HTTPD $ARGV
I then backed out the change and retried, got the same error.
killall httpd
then try it again :)
httpd was not running and I have been running Apache 2x with mod_perl 1.99x for over two months now. It started with a problem I traced to env. var $ENV{HTTP_ACCEPT}. I figured out that I needed PerlOptions +SetupENV. So I added this, stopped and tried to start Apache. That's when I got this shock.
In other words there's an Apache still running when you're trying to
start a second one which wants to listen on the same socket that the
first Apache is already listening on. That isn't permitted.
But you shouldn't be getting segmentation faults in that case so
something else is probably wrong too. Did you build from source?
Did you follow the instructions in the Guide? Linux? 1.3.27/1.27?
DSO? Maybe you can post the information requested in the docs?
73,
Ged.
The 'top' output is : 3:38am up 8 days, 22:58, 1 user, load average:
0.00, 0.00, 0.00
22 processes: 21 sleeping, 1 running, 0 zombie, 0 stopped
CPU states: 0.0% user, 0.3% system, 0.0% nice, 99.6% idle
Mem: 970768K av, 212504K used, 758264K free,7852K shrd, 98668K
buff
Swap: 530104K av,3216K used, 526888K free 88104K
cached
PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND
16688 kairanga 10 0 996 996 800 R 0.3 0.1 0:00 top
1 root 0 076 6448 S 0.0 0.0 0:10 init
2 root 0 0 00 0 SW0.0 0.0 0:00 kflushd
3 root 8 0 00 0 SW0.0 0.0 34:03 kupdate
4 root 0 0 00 0 SW0.0 0.0 9:07 kswapd
5 root 0 0 00 0 SW0.0 0.0 0:00 keventd
57 root 0 0 232 232 0 S 0.0 0.0 0:00 rc.M
77 root 2 0 272 272 160 S 0.0 0.0 2:20 syslogd
80 root 0 0 640 640 128 S 0.0 0.0 0:00 klogd
82 root 0 0 368 324 220 S 0.0 0.0 0:04 sshd
86 root 6 0 336 336 240 S 0.0 0.0 0:00 crond
93 root 2 0 692 488 292 S 0.0 0.0 0:03 sendmail
100 root 0 0 2352 1708 936 S 0.0 0.1 0:07 poprelayd
102 root 0 0 2668 1248 292 S 0.0 0.1 0:00 miniserv.pl
104 root 0 0 220 168 148 S 0.0 0.0 0:00 inetd
105 root 0 0 184 184 0 S 0.0 0.0 0:00 safe_mysqld
127 mysql 0 0 2384 2384 1364 S 0.0 0.2 0:00 mysqld
129 mysql 0 0 2384 2384 1364 S 0.0 0.2 0:00 mysqld
130 mysql 0 0 2384 2384 1364 S 0.0 0.2 0:00 mysqld
16316 root 0 0 1284 1268 1124 S 0.0 0.1 0:00 sshd
16318 kairanga 0 0 1364 1352 1208 S 0.0 0.1 0:00 sshd
16319 kairanga 3 0 1240 1240 964 S 0.0 0.1 0:00 bash
There has been no change to Apache httpd.conf other than the addition
of PerlOptions +SetupEnv which I commented out anyway.
How can I get a list of ports being used so I can kill the processes? As
far as I can tell httpd is not running. The IP is 208.179.25.28
I dont see any apparent signs of hacking either.
RE: Apache config problem .. please help
You can use
netstat -a
to list all the ports in use--look for your configured port or 'http'
you might wanna try
ps -ef | grep http
to search for a process not in top's display (can you see all? Try
setting n=100 and expanding xterm (if using one)).
If 'ps -ef | grep http' returns nothing check to make sure your PID file
isn't still there. Most likely /usr/local/apache/logs/httpd.pid . If
it is there and you're sure httpd's not running remove the file and try
/usr/local/apache/bin/apachectl stop
/usr/local/apache/bin/apachectl start
good luck,
bill
-Original Message-
From: Ranga Nathan [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 03, 2003 1:51 PM
Cc: mod_perl Mailing List
Subject: Re: Apache config problem .. please help
Ged Haywood wrote:
Hi there,
On Thu, 3 Jul 2003, Dennis Stout wrote:
I made a simple mod_perl change to the config and when restarting
Apache
I got this error:
(98)Address already in use: make_sock: could not bind to address
0.0.0.0:2250
no listening sockets available, shutting down
/usr/local/apache/bin/apachectl: line 87: 16512 Segmentation fault
$HTTPD $ARGV
I then backed out the change and retried, got the same error.
killall httpd
then try it again :)
httpd was not running and I have been running Apache 2x with mod_perl
1.99x for over two months now. It started with a problem I traced to
env. var $ENV{HTTP_ACCEPT}. I figured out that I needed PerlOptions
+SetupENV. So I added this, stopped and tried to start Apache. That's
when I got this shock.
In other words there's an Apache still running when you're trying to
start a second one which wants to listen on the same socket that the
first Apache is already listening on. That isn't permitted.
But you shouldn't be getting segmentation faults in that case so
something else is probably wrong too. Did you build from source?
Did you follow the instructions in the Guide? Linux? 1.3.27/1.27?
DSO? Maybe you can post the information requested in the docs?
73,
Ged.
The 'top' output is : 3:38am up 8 days, 22:58, 1 user, load average:
0.00, 0.00, 0.00
22 processes: 21 sleeping, 1 running, 0 zombie, 0 stopped
CPU states: 0.0% user, 0.3% system, 0.0% nice, 99.6% idle
Mem: 970768K av, 212504K used, 758264K free,7852K shrd, 98668K
buff
Swap: 530104K av,3216K used, 526888K free 88104K
cached
PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND
16688 kairanga 10 0 996 996 800 R 0.3 0.1 0:00 top
1 root 0 076 6448 S 0.0 0.0 0:10 init
2 root 0 0 00 0 SW0.0 0.0 0:00 kflushd
3 root 8 0 00 0 SW0.0 0.0 34:03 kupdate
4 root 0 0 00 0 SW0.0 0.0 9:07 kswapd
5 root 0 0 00 0 SW0.0 0.0 0:00 keventd
57 root 0 0 232 232 0 S 0.0 0.0 0:00 rc.M
77 root 2 0 272 272 160 S 0.0 0.0 2:20 syslogd
80 root 0 0 640 640 128 S 0.0 0.0 0:00 klogd
82 root 0 0 368 324 220 S 0.0 0.0 0:04 sshd
86 root 6 0 336 336 240 S 0.0 0.0 0:00 crond
93 root 2 0 692 488 292 S 0.0 0.0 0:03 sendmail
100 root 0 0 2352 1708 936 S 0.0 0.1 0:07 poprelayd
102 root 0 0 2668 1248 292 S 0.0 0.1 0:00
miniserv.pl
104 root 0 0 220 168 148 S 0.0 0.0 0:00 inetd
105 root 0 0 184 184 0 S 0.0 0.0 0:00
safe_mysqld
127 mysql 0 0 2384 2384 1364 S 0.0 0.2 0:00 mysqld
129 mysql 0 0 2384 2384 1364 S 0.0 0.2 0:00 mysqld
130 mysql 0 0 2384 2384 1364 S 0.0 0.2 0:00 mysqld
16316 root 0 0 1284 1268 1124 S 0.0 0.1 0:00 sshd
16318 kairanga 0 0 1364 1352 1208 S 0.0 0.1 0:00 sshd
16319 kairanga 3 0 1240 1240 964 S 0.0 0.1 0:00 bash
There has been no change to Apache httpd.conf other than the addition
of PerlOptions +SetupEnv which I commented out anyway.
How can I get a list of ports being used so I can kill the processes? As
far as I can tell httpd is not running. The IP is 208.179.25.28
I dont see any apparent signs of hacking either.
CONFIDENTIALITY NOTICE: This E-Mail is intended only
for the use of the individual or entity to which it is addressed and may contain
information that is privileged, confidential and exempt from disclosure under
applicable law. If you have received this communication in error, please do not
distribute and delete the original message. Please notify the sender by E-Mail at the
address shown. Thank you for your compliance.
Re: Apache config problem .. please help
I know this is not of much help, but I have had situations where a badly terminating process would prevent subsequent processes from using that port. on windows, i never found a solution other than to reboot. on solaris 7, i never found a solution other than to wait 8 minutes. I did some reading and found socket inet options to change how such programs bound thge port so as to allow others to use it in more friendly a fashion but such a change wasnt possible with the process in question. -- gedanken
Re: Apache config problem .. please help
Hi there, On Thu, 3 Jul 2003, Ranga Nathan wrote: In other words there's an Apache still running The 'top' output is : [snip] How can I get a list of ports being used so I can kill the processes? As I said, there may be more wrong than just what's obvious. It looks like the obvious explanation that another Apache is running is not the right one. At the risk of asking questions I wouldn't have to ask if you'd posted the information I asked for, why port 2205? That's not what I'd expect to see, but without more information I'm groping about in the dark. What's trying to use that port? MySQL perhaps? Why not stop it first, or change the port that Apache is trying to use, or the port that whatever apachectl is trying to start is trying to use, or... As far as I can tell httpd is not running. The IP is 208.179.25.28 c2h5oh:~$ ping 208.179.25.28 PING 208.179.25.28 (208.179.25.28): 56 data bytes 64 bytes from 208.179.25.28: icmp_seq=0 ttl=236 time=389.6 ms --- 208.179.25.28 ping statistics --- 2 packets transmitted, 1 packets received, 50% packet loss round-trip min/avg/max = 389.6/389.6/389.6 ms c2h5oh:~$ telnet 208.179.25.28 80 Trying 208.179.25.28... telnet: Unable to connect to remote host: Connection refused Looks like you're right. Have you read the stuff I mentioned? I dont see any apparent signs of hacking either. Don't go tilting at windmills just yet. :) 73, Ged.
Re: require'ing data files under mod_perl
On Thu, 2003-07-03 at 13:38, Peter Ensch wrote:
I'm using CGI::Application and this part of the code happens inside
the cgiapp_init() method which I'm overriding:
our $USERS : unique = /path/to/users.dat;
sub cgiapp_init {
my $self = shift;
$self-param('users' = require ${\$USERS});
}
That's confusing code. Your users.dat file is a chunk of code that
returns a value that you use? A little obscure, in my opinion. And
what's that stuff with the ref/de-ref syntax for?
So, to reiterate, I may write to users.dat on one transaction
and read on another; the file contents is always up-to-date.
The file is up-to-date, or the param 'users' is?
Why don't you debug it a little by putting a warn statement in your
users.dat file that prints the process ID? Then you can tell if it is
truly being executed more than once by the same process.
- Perrin
Re: Apache config problem .. please help
Gedanken wrote: I know this is not of much help, but I have had situations where a badly terminating process would prevent subsequent processes from using that port. on windows, i never found a solution other than to reboot. on solaris 7, i never found a solution other than to wait 8 minutes. I did some reading and found socket inet options to change how such programs bound thge port so as to allow others to use it in more friendly a fashion but such a change wasnt possible with the process in question. The problem is resolved. Unbenownst to me - I need to investigate this - the Listen IP:port line in Apache had the wrong IP address. I really dont know how this happened. The number is so different yet syntactically correct to be a keystroke error. Thanks everyone for pitching in. For one I can now use ' netstat' utility to check ports being used,. Thanks Ged! I keep talking to my corporate IT people about open source , and they constantly ask me 'who will support it? what do they get out of it?' . I can not even begin to explain to them the 'connectedness' across the 'net. Should people always measure everything in terms of money? Anyway, all this started from an attempt to access env. vars from legacy scripts running under registry. What is the easiest way to get env. var access without the accompanying performance penalty that mod_perl documentation talks about? Regards
Re: require'ing data files under mod_perl
On Thu, Jul 03, 2003 at 02:51:23PM -0400, Perrin Harkins wrote:
On Thu, 2003-07-03 at 13:38, Peter Ensch wrote:
I'm using CGI::Application and this part of the code happens inside
the cgiapp_init() method which I'm overriding:
our $USERS : unique = /path/to/users.dat;
sub cgiapp_init {
my $self = shift;
$self-param('users' = require ${\$USERS});
}
That's confusing code. Your users.dat file is a chunk of code that
returns a value that you use? A little obscure, in my opinion. And
what's that stuff with the ref/de-ref syntax for?
The file contains a simple hash ref. like
{
duck = 'quack',
dog = 'woof',
cat = 'meow',
}
The ref/de-ref was a mistake; a hold over from when USERS was a
constant (and which didn't interpolate in a require). Now it's
$self-param('users' = require $USERS);
So, to reiterate, I may write to users.dat on one transaction
and read on another; the file contents is always up-to-date.
The file is up-to-date, or the param 'users' is?
The file is. IE. it gets written and and the new stuff is available
by simply reloading the page.
Why don't you debug it a little by putting a warn statement in your
users.dat file that prints the process ID? Then you can tell if it is
truly being executed more than once by the same process.
Hmm. Not sure how to do that w/out messing w/ the headers and
making the app. crash. How would I do that?
P
--
^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^
Peter Ensch,
[EMAIL PROTECTED] A-1140 (214) 480 2333
^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^
Re: require'ing data files under mod_perl
On Thu, 2003-07-03 at 16:16, Peter Ensch wrote: So, to reiterate, I may write to users.dat on one transaction and read on another; the file contents is always up-to-date. The file is up-to-date, or the param 'users' is? The file is. IE. it gets written and and the new stuff is available by simply reloading the page. Well, the file getting written is not related to require loading each time or not. The thing that I would not expect to change is the in-memory data. Why don't you debug it a little by putting a warn statement in your users.dat file that prints the process ID? Then you can tell if it is truly being executed more than once by the same process. Hmm. Not sure how to do that w/out messing w/ the headers and making the app. crash. How would I do that? Before the hash stuff in the file, put in a statement like this: warn users.dat loaded by process $$; - Perrin
Re: require'ing data files under mod_perl
On Thu, Jul 03, 2003 at 04:24:35PM -0400, Perrin Harkins wrote: On Thu, 2003-07-03 at 16:16, Peter Ensch wrote: So, to reiterate, I may write to users.dat on one transaction and read on another; the file contents is always up-to-date. The file is up-to-date, or the param 'users' is? The file is. IE. it gets written and and the new stuff is available by simply reloading the page. Well, the file getting written is not related to require loading each time or not. The thing that I would not expect to change is the in-memory data. Why don't you debug it a little by putting a warn statement in your users.dat file that prints the process ID? Then you can tell if it is truly being executed more than once by the same process. Hmm. Not sure how to do that w/out messing w/ the headers and making the app. crash. How would I do that? Before the hash stuff in the file, put in a statement like this: warn users.dat loaded by process $$; OK. Thanks. Well, yes it is being reloaded whenever the form is submitted and w/out restarting the server. Here's some of the output (error_log): [Thu Jul 3 15:52:00 2003] users.dat: users.dat loaded by process 18294 at /opt/a... [Thu Jul 3 15:52:00 2003] users.dat: users.dat loaded by process 18294 at /opt/a... [Thu Jul 3 15:52:00 2003] users.dat: users.dat loaded by process 18294 at /opt/a... [Thu Jul 3 15:52:03 2003] users.dat: users.dat loaded by process 18294 at /opt/a... [Thu Jul 3 15:52:04 2003] users.dat: users.dat loaded by process 18294 at /opt/a... [Thu Jul 3 15:52:06 2003] users.dat: users.dat loaded by process 18294 at /opt/a... [Thu Jul 3 15:52:32 2003] users.dat: users.dat loaded by process 18294 at /opt/a... [Thu Jul 3 15:52:33 2003] users.dat: users.dat loaded by process 18338 at /opt/a... [Thu Jul 3 15:52:34 2003] users.dat: users.dat loaded by process 18338 at /opt/a... [Thu Jul 3 15:53:00 2003] users.dat: users.dat loaded by process 18338 at /opt/a... [Thu Jul 3 15:53:03 2003] users.dat: users.dat loaded by process 18338 at /opt/a... [Thu Jul 3 15:53:05 2003] users.dat: users.dat loaded by process 18338 at /opt/a... [Thu Jul 3 15:53:22 2003] users.dat: users.dat loaded by process 18338 at /opt/a... [Thu Jul 3 15:53:25 2003] users.dat: users.dat loaded by process 18338 at /opt/a... [Thu Jul 3 15:53:28 2003] users.dat: users.dat loaded by process 18338 at /opt/a... [Thu Jul 3 15:53:28 2003] users.dat: users.dat loaded by process 18338 at /opt/a... Here are the httpd process: [490] % ps -Alf |grep apache 8 S root 17921 ... /apps/apache/http/2.0.46/worker/bin 8 S apache 18338 ... /apps/apache/http/2.0.46/worker/bin 8 S apache 18336 ... /apps/apache/http/2.0.46/worker/bin 8 S apache 18337 ... /apps/apache/http/2.0.46/worker/bin So. What's going on? I'm not using A::Reload. P -- ^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^ Peter Ensch, [EMAIL PROTECTED] A-1140 (214) 480 2333 ^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^
Re: require'ing data files under mod_perl
On Thu, 2003-07-03 at 16:59, Peter Ensch wrote: OK. Thanks. Well, yes it is being reloaded whenever the form is submitted and w/out restarting the server. Here's some of the output (error_log): [Thu Jul 3 15:52:00 2003] users.dat: users.dat loaded by process 18294 at /opt/a... [Thu Jul 3 15:52:00 2003] users.dat: users.dat loaded by process 18294 at /opt/a... [Thu Jul 3 15:52:00 2003] users.dat: users.dat loaded by process 18294 at /opt/a... [Thu Jul 3 15:52:03 2003] users.dat: users.dat loaded by process 18294 at /opt/a... [Thu Jul 3 15:52:04 2003] users.dat: users.dat loaded by process 18294 at /opt/a... [Thu Jul 3 15:52:06 2003] users.dat: users.dat loaded by process 18294 at /opt/a... [Thu Jul 3 15:52:32 2003] users.dat: users.dat loaded by process 18294 at /opt/a... [Thu Jul 3 15:52:33 2003] users.dat: users.dat loaded by process 18338 at /opt/a... [Thu Jul 3 15:52:34 2003] users.dat: users.dat loaded by process 18338 at /opt/a... [Thu Jul 3 15:53:00 2003] users.dat: users.dat loaded by process 18338 at /opt/a... [Thu Jul 3 15:53:03 2003] users.dat: users.dat loaded by process 18338 at /opt/a... [Thu Jul 3 15:53:05 2003] users.dat: users.dat loaded by process 18338 at /opt/a... [Thu Jul 3 15:53:22 2003] users.dat: users.dat loaded by process 18338 at /opt/a... [Thu Jul 3 15:53:25 2003] users.dat: users.dat loaded by process 18338 at /opt/a... [Thu Jul 3 15:53:28 2003] users.dat: users.dat loaded by process 18338 at /opt/a... [Thu Jul 3 15:53:28 2003] users.dat: users.dat loaded by process 18338 at /opt/a... Just a guess, but maybe this is because you're passing a variable to the require function. Try hard-coding it and see if it changes. - Perrin
MP1, Redhat 7.3: Transmission size limited after some time
Hi all,
I got a really odd problem: I have identical mod_perl/apache installs
on FreeBSD 3.x systems and a few Redhat 7.3 systems.
After some time running OK, the Redhat systems start acting up.
Transmissions are suddenly cut of after somewhere between 90 and 150
kb. Absolutely nothing in any logs is indicating a problem. Dynamic web
pages sent via print are affected the same as downloads sent via
$r-send_fd('FH');.
Restarting the web server fixes it, but a few hours/days later the
problem resurfaces. Anyone encountered something similar? Any pointers
as to how to debug this? I have ruled out problems with external
hardware or proxies, as that problem occurs equally on systems in
radically different environments.
Thanks for any pointers
Gerd
