Re: mod_perl 1.0 to 2.0 migration

[Chris Bennett]

On Sun, Nov 27, 2022 at 08:49:29AM +0800, Host Cache wrote:
> On 2022-11-21 23:16, Xinhuan Zheng wrote:
> > Hi All,
> > 
> > We need to migrate our codebase from mod_perl 1.0 to 2.0. In our
> > codebase, we have used “use Apache::Constants”. We want to change
> > it to be like:
> > https://perl.apache.org/docs/2.0/user/porting/compat.html#mod_perl_1_0_and_2_0_Constants_Coexistence
> > [1]. Our codebase are not only used in mod_perl environment, they are
> > also used in Non mod_perl environment, like standalone program calling
> > the modules in codebase. What should we change for “use
> > Apache::Constants” in Non mod_perl environment?
> > 
> 
> That's impossible. Apache::* modules are for modperl only.

You can send the program to either the mod_perl2 modules when mod_perl
is running. Otherwise, you can use non-mod_perl modules when it's not.
Most of the code can probably be left unchanged with a little luck.

It depends a lot on how complex or exactly what is needed, but there are
many options. CGI::Compile, for example could add that mod_perlish sort
of effect. I was very tempted to learn a new framework when I had to
change from version 1 over to 2, but it was really much easier for me to
make a few code changes in lots of files rather than start from scratch.
I actually ended up with better code after fixing those little bugs that
were not worth the effort when writing it originally.

-- 
Chris Bennett

Re: mod_perl 1.0 to 2.0 migration

[Host Cache]

On 2022-11-21 23:16, Xinhuan Zheng wrote:

Hi All,

We need to migrate our codebase from mod_perl 1.0 to 2.0. In our
codebase, we have used “use Apache::Constants”. We want to change
it to be like:
https://perl.apache.org/docs/2.0/user/porting/compat.html#mod_perl_1_0_and_2_0_Constants_Coexistence
[1]. Our codebase are not only used in mod_perl environment, they are
also used in Non mod_perl environment, like standalone program calling
the modules in codebase. What should we change for “use
Apache::Constants” in Non mod_perl environment?



That's impossible. Apache::* modules are for modperl only.

Re: mod_perl and mod_python

[Joe Schaefer]

Its got a GIL and it cores frequently and it’s not exposing much of the
httpd/apr.  It’s not that popular compared to wsgi.

On Fri, Aug 19, 2022 at 10:20 PM pengyh  wrote:

> I know perl and python a bit well, most time use both of them for work.
> besides mod_perl, there is also mod_python.
> do you know what's the difference between them?
> I never heard people using mod_python to make some jobs.
>
> Thanks
>
-- 
Joe Schaefer, Ph.D.
We only build what you need built.

954.253.3732 

Re: mod_perl and mod_python

[Mithun Bhattacharya]

That is because unlike mod_perl mod_python doesn't integrate deeply into
Apache and you can't extend every HTTP request cycle phases.

Only two programming languages integrate that deeply - C and Perl.

On Fri, Aug 19, 2022, 7:19 PM pengyh  wrote:

> I know perl and python a bit well, most time use both of them for work.
> besides mod_perl, there is also mod_python.
> do you know what's the difference between them?
> I never heard people using mod_python to make some jobs.
>
> Thanks
>

Re: mod_perl alternatives

[Perrin Harkins]

I don't think there's any sudden urgency to switch to something else, since
nothing has actually changed about the state of mod_perl. However, if you
do want to migrate to something else, you should look at Plack:
https://metacpan.org/pod/Plack

Plack is not a drop-in replacement for mod_perl, but it's a high-quality
project with a well-developed ecosystem that will have some sort of
solution for most (not all) things that people are doing in mod_perl. But
again, I don't think you need to rush to do anything here.

- Perrin

On Thu, Mar 18, 2021 at 12:01 AM Jim Albert  wrote:

> Given the recent discussion on the need for mod_perl PMC members and the
> disclosure that there is no active development on mod_perl this seems
> like an appropriate time to start a thread on a discussion of mod_perl
> alternatives inline with the various means of using mod_perl from the
> low level use of interfacing with the Apache server to the quick and
> dirty stuff (ModPerl::PerlRun, I believe to keep Perl and modules in
> memory).
>
> I've seen mod_fcgid proposed in posts on other forums. Has anyone played
> with alternatives? I expect the low level Apache interaction might be
> difficult to duplicate at least to continue to do so in Perl. Perhaps
> the ModPerl::PerlRun approach of keeping Perl and modules in memory is a
> potential starting point for discussion for those using mod_perl at the
> most basic level.
>
> Jim
>
>
>
>

RE: mod_perl alternatives [EXT]

[James Smith]

The problem is I don't think there is mod_perl is quite a unique infrastructure 
- across all language I believe! I don't think any other language/framework 
gives you this level of flexibility.

Most frameworks just concentrate on the request phase and shoe horn everything 
in there - so you can't mix and match which technologies you use for different 
parts of the release cycle.

I looked at rewriting our framework in PSGI - dancer - and although it is 
possible we would have had to throw away 50% of the ultra-cool features or 
implement a fake request cycle with the request phase {to mimic what most 
dancer developers do anyway} but then putting the configurable logic in would 
add a whole new issue - apache has this nice config framework all setup you can 
use.

The other bit that as missing was the non-Perl part to be able to have 
different parts of the process handled by different languages (even the 
response phase)

-Original Message-
From: Jim Albert  
Sent: 18 March 2021 04:01
To: modperl@perl.apache.org
Subject: mod_perl alternatives [EXT]

Given the recent discussion on the need for mod_perl PMC members and the 
disclosure that there is no active development on mod_perl this seems like an 
appropriate time to start a thread on a discussion of mod_perl alternatives 
inline with the various means of using mod_perl from the low level use of 
interfacing with the Apache server to the quick and dirty stuff 
(ModPerl::PerlRun, I believe to keep Perl and modules in memory).

I've seen mod_fcgid proposed in posts on other forums. Has anyone played with 
alternatives? I expect the low level Apache interaction might be difficult to 
duplicate at least to continue to do so in Perl. Perhaps the ModPerl::PerlRun 
approach of keeping Perl and modules in memory is a potential starting point 
for discussion for those using mod_perl at the most basic level.

Jim






-- 
 The Wellcome Sanger Institute is operated by Genome Research 
 Limited, a charity registered in England with number 1021457 and a 
 company registered in England with number 2742969, whose registered 
 office is 215 Euston Road, London, NW1 2BE.

Re: mod_perl, compilation issues, cont

[tomcat/perl]

Additional info :

I checked the permissions of all below c:/strawberry/perl, and one thing I can say is that 
all directories and files below that point have at least permissions read/write/execute 
for all "authenticated users".


On the other hand, I also ran the following (why did I not think of that before ?), just 
to make sure that the issue would be reproducible with only the "vanilla" installed Apache 
2.4, perl 5.26.3, mod_perl 2.x :


C:\strawberry\perl\site>set PERL_DL_DEBUG=1

C:\strawberry\perl\site>perl -cw C:/Strawberry/perl/site/lib/Apache2/Const.pm
DynaLoader.pm loaded (C:/Strawberry/perl/site/lib C:/Strawberry/perl/vendor/lib 
C:/Strawberry/perl/lib, C:\STRAWB~1\c\lib C:\STRAWB~1\c\x86_64-w64-mingw32\lib 
C:\STRAWB~1\c\lib\gcc\x86_64-w64-mingw32\7.1.0)

DynaLoader::bootstrap for ModPerl::Const (auto/ModPerl/Const/Const.xs.dll)
dl_findfile(-LC:/Strawberry/perl/site/lib/auto/ModPerl/Const -LC:/Strawberry/perl/site/lib 
-LC:/Strawberry/perl/vendor/lib -LC:/Strawberry/perl/lib Const)

 checking in C:/Strawberry/perl/site/lib/auto/ModPerl/Const for Const.xs.dll
 checking in C:/Strawberry/perl/site/lib/auto/ModPerl/Const for Const.dll
dl_findfile found: C:/Strawberry/perl/site/lib/auto/ModPerl/Const/Const.dll
Can't load 'C:/Strawberry/perl/site/lib/auto/ModPerl/Const/Const.dll' for module 
ModPerl::Const: load_file:Das angegebene Modul wurde nicht gefunden at 
C:/Strawberry/perl/lib/DynaLoader.pm line 193.

  at C:/Strawberry/perl/site/lib/Apache2/Const.pm line 19.
Compilation failed in require at C:/Strawberry/perl/site/lib/Apache2/Const.pm 
line 19.
BEGIN failed--compilation aborted at 
C:/Strawberry/perl/site/lib/Apache2/Const.pm line 19.

(Note : to make extra sure, I also ran this in a CMD window "run as administrator"; the 
results are the same.)



Any other clue, anyone ?

>perl -V :

 C:\strawberry\perl\site>perl -V
Summary of my perl5 (revision 5 version 26 subversion 3) configuration:

  Platform:
osname=MSWin32
osvers=10.0.17134.407
archname=MSWin32-x64-multi-thread
uname='Win32 strawberry-perl 5.26.3.1 #1 Sun Dec  2 22:57:44 2018 x64'
config_args='undef'
hint=recommended
useposix=true
d_sigaction=undef
useithreads=define
usemultiplicity=define
use64bitint=define
use64bitall=undef
uselongdouble=undef
usemymalloc=n
default_inc_excludes_dot=define
bincompat5005=undef
  Compiler:
cc='gcc'
ccflags =' -s -O2 -DWIN32 -DWIN64 -DCONSERVATIVE -D__USE_MINGW_ANSI_STDIO 
-DPERL_TEXTMODE_SCRIPTS -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -DUSE_PERLIO -fwrapv 
-fno-strict-aliasing -mms-bitfields'

optimize='-s -O2'
cppflags='-DWIN32'
ccversion=''
gccversion='7.1.0'
gccosandvers=''
intsize=4
longsize=4
ptrsize=8
doublesize=8
byteorder=12345678
doublekind=3
d_longlong=define
longlongsize=8
d_longdbl=define
longdblsize=16
longdblkind=3
ivtype='long long'
ivsize=8
nvtype='double'
nvsize=8
Off_t='long long'
lseeksize=8
alignbytes=8
prototype=define
  Linker and Libraries:
ld='g++'
ldflags ='-s -L"C:\STRAWB~1\perl\lib\CORE" -L"C:\STRAWB~1\c\lib"'
libpth=C:\STRAWB~1\c\lib C:\STRAWB~1\c\x86_64-w64-mingw32\lib 
C:\STRAWB~1\c\lib\gcc\x86_64-w64-mingw32\7.1.0
libs= -lmoldname -lkernel32 -luser32 -lgdi32 -lwinspool -lcomdlg32 -ladvapi32 
-lshell32 -lole32 -loleaut32 -lnetapi32 -luuid -lws2_32 -lmpr -lwinmm -lversion -lodbc32 
-lodbccp32 -lcomctl32
perllibs= -lmoldname -lkernel32 -luser32 -lgdi32 -lwinspool -lcomdlg32 -ladvapi32 
-lshell32 -lole32 -loleaut32 -lnetapi32 -luuid -lws2_32 -lmpr -lwinmm -lversion -lodbc32 
-lodbccp32 -lcomctl32

libc=
so=dll
useshrplib=true
libperl=libperl526.a
gnulibc_version=''
  Dynamic Linking:
dlsrc=dl_win32.xs
dlext=xs.dll
d_dlsymun=undef
ccdlflags=' '
cccdlflags=' '
lddlflags='-mdll -s -L"C:\STRAWB~1\perl\lib\CORE" -L"C:\STRAWB~1\c\lib"'


Characteristics of this binary (from libperl):
  Compile-time options:
HAS_TIMES
HAVE_INTERP_INTERN
MULTIPLICITY
PERLIO_LAYERS
PERL_COPY_ON_WRITE
PERL_DONT_CREATE_GVSV
PERL_IMPLICIT_CONTEXT
PERL_IMPLICIT_SYS
PERL_MALLOC_WRAP
PERL_OP_PARENT
PERL_PRESERVE_IVUV
USE_64_BIT_INT
USE_ITHREADS
USE_LARGE_FILES
USE_LOCALE
USE_LOCALE_COLLATE
USE_LOCALE_CTYPE
USE_LOCALE_NUMERIC
USE_LOCALE_TIME
USE_PERLIO
USE_PERL_ATOF
  Built under MSWin32
  Compiled at Dec  2 2018 23:03:33
  %ENV:
PERL_DL_DEBUG="1"
  @INC:
C:/Strawberry/perl/site/lib
C:/Strawberry/perl/vendor/lib
C:/Strawberry/perl/lib

C:\strawberry\perl\site>

Environment :
C:\strawberry\perl\site>set
ALLUSERSPROFILE=C:\ProgramData
APPDATA=C:\Users\aw\AppData\Roaming
CommonProgramFiles=C:\Program Files\Common Files
CommonProgramFiles(x86)=C:\Program Files (x86)\Common Files
CommonProgramW6432=C:\Program Files\Common Files
COMPUTERNAME=ANDRE-PC
ComSpec=C:\WINDOWS\system

Re: mod_perl, compilation issues, cont

[tomcat/perl]

Thank you very much for your reply below. I was getting desperate of getting 
any at all.
I will check the permissions issue and post back to the list.

Maybe in the mneantime an additional question to the list : has *anyone at all* succeeded 
in installing (and using) Apache 2.4 / perl 5.20+ / mod_perl 2.x on a Windows 10 platform ?
Knowing that someone else has been able to do that, would already help me in focusing my 
debugging efforts to something specific to my laptop.



On 31.01.2020 16:45, Bruce Johnson wrote:
I am not a Windows expert by any means, but it it possible that it’s a permissions issue 
on that DLL file or enclosing directory(s)?  Folder permissions in Windows will let you 
grant directory listing rights but not read rights for the process that’s doing the 
compilation…


See: 
https://www.online-tech-tips.com/computer-tips/set-file-folder-permissions-windows/ under 
Permission Types; the specific right is ‘List Folder Contents’


This would account for both dl_findfile working and the ‘Can’t Load file’ error because 
the first utilizes the listing rights and the second needs to actually read the file.




On Jan 16, 2020, at 1:34 AM, André Warnier (tomcat/perl) > wrote:


Can anyone tell me what the error below really means ?
(and if possible, give me a clue as to what may be happening ?)

To get possibly more details, I re-ran the compile command after setting PERL_DL_DEBUG 
in the environment (just something I found in Dynaloader.pm). It does give some more 
detail, but I am still stumped..


Full config described below.
D:\develop\06_SVN\AP2lib\trunk\modlib\AUTH\UMA2.pm is my module, which compiles just 
fine on Linux servers with similar software installed (Apache, mod_perl, perl).



C:\>perl -cw D:\develop\06_SVN\AP2lib\trunk\modlib\AUTH\UMA2.pm
DynaLoader.pm loaded (C:/Strawberry/perl/site/lib C:/Strawberry/perl/vendor/lib 
C:/Strawberry/perl/lib, C:\STRAWB~1\c\lib C:\STRAWB~1\c\x86_64-w64-mingw32\lib 
C:\STRAWB~1\c\lib\gcc\x86_64-w64-mingw32\7.1.0)

DynaLoader::bootstrap for ModPerl::Const (auto/ModPerl/Const/Const.xs.dll)
dl_findfile(-LC:/Strawberry/perl/site/lib/auto/ModPerl/Const 
-LC:/Strawberry/perl/site/lib -LC:/Strawberry/perl/vendor/lib -LC:/Strawberry/perl/lib 
Const)

checking in C:/Strawberry/perl/site/lib/auto/ModPerl/Const for Const.xs.dll
checking in C:/Strawberry/perl/site/lib/auto/ModPerl/Const for Const.dll
dl_findfile found: C:/Strawberry/perl/site/lib/auto/ModPerl/Const/Const.dll
Can't load 'C:/Strawberry/perl/site/lib/auto/ModPerl/Const/Const.dll' for module 
ModPerl::Const: load_file:Das angegebene Modul wurde nicht gefunden at 
C:/Strawberry/perl/lib/DynaLoader.pm line 193.

 at C:/Strawberry/perl/site/lib/Apache2/Const.pm line 19.
Compilation failed in require at C:/Strawberry/perl/site/lib/Apache2/Const.pm 
line 19.
BEGIN failed--compilation aborted at 
C:/Strawberry/perl/site/lib/Apache2/Const.pm line 19.
Compilation failed in require at 
D:\develop\06_SVN\AP2lib\trunk\modlib\AUTH\UMA2.pm line 28.
BEGIN failed--compilation aborted at D:\develop\06_SVN\AP2lib\trunk\modlib\AUTH\UMA2.pm 
line 28.


-

OS : Windows 10
Apache httpd 2.4.41
perl (Strawberry) : perl 5, version 26, subversion 2 (v5.26.2) built for 
MSWin32-x64-multi-thread

mod_perl : from Steve Hay's mod_perl-2.0.10-strawberryperl-5.26.1.1-64bit.zip,
as per Apache log :
Apache/2.4.41 (Win64) mod_perl/2.0.10 Perl/v5.26.2 configured

Problem :

C:\>perl -cw D:\develop\06_SVN\AP2lib\trunk\modlib\AUTH\UMA2.pm
Can't load 'C:/Strawberry/perl/site/lib/auto/ModPerl/Const/Const.dll' for module 
ModPerl::Const: load_file:Das angegebene Modul wurde nicht gefunden at 
C:/Strawberry/perl/lib/DynaLoader.pm line 193.

 at C:/Strawberry/perl/site/lib/Apache2/Const.pm line 19.
Compilation failed in require at C:/Strawberry/perl/site/lib/Apache2/Const.pm 
line 19.
BEGIN failed--compilation aborted at 
C:/Strawberry/perl/site/lib/Apache2/Const.pm line 19.
Compilation failed in require at 
D:\develop\06_SVN\AP2lib\trunk\modlib\AUTH\UMA2.pm line 28.
BEGIN failed--compilation aborted at D:\develop\06_SVN\AP2lib\trunk\modlib\AUTH\UMA2.pm 
line 28.


Line 28 of UMA2.pm is :

use Apache2::Const -compile => qw(:common :http :methods :override :proxy :log REDIRECT 
AUTHZ_GRANTED AUTHZ_DENIED AUTHZ_DENIED_NO_USER AUTHZ_GENERAL_ERROR);


(wrapping due to email)

C:/Strawberry/perl/site/lib/Apache2/Const.pm line 19 is :

use ModPerl::Const ();

File C:\strawberry\perl\site\lib\ModPerl\Const.pm exists, but has no 
"load_file" in it.

The file C:/Strawberry/perl/site/lib/auto/ModPerl/Const/Const.dll exists.

For non-german-speakers, the above message "load_file:Das angegebene Modul wurde nicht 
gefunden" translates as "load_file:the specified module was not found".


The above module "UMA2.pm" compiles without error on a Linux server with similar httpd, 
perl and mod_perl versions.


Any clue or additional questions welcome.
Thanks


--
Bruce Johnson
University of Arizona
College 

Re: mod_perl , ChildInitHandler, OpenApi

[Randolf Richardson]

You can use the $r->pnotes to pass blessed Perl objects between 
handlers that run at different phases:

Apache2::RequestUtil -- $r->pnotes

https://perl.apache.org/docs/2.0/api/Apache2/RequestUtil.html#C_pnotes_

(I'm assuming that you're using mod_perl2.)

> Hi, 
> 
> we're running our application build with mod_perl and 
> MasonX::WebApp::ApacheHandler  (quite old, yes I know)
> Now I would like to use OpenAPI::Client to connect to some other web services 
> we need. OpenAPI::Client generates code based on the api specification, but 
> this takes 3 -4 seconds , which is far too slow to call it on every request. 
> How can I initialize the OpenAPI::Client during server startup and use the 
> compiled code later ( i.e. access the object created)?  I'm thinking about 
> doing this in  a ChildInitHandler, but I have no idea, where to "store" the 
> result. We're using mom_event in production, anything to consider with this ? 
> 
> Thanks
> Rolf  
> 


Randolf Richardson - rand...@inter-corporate.com
Inter-Corporate Computer & Network Services, Inc.
Beautiful British Columbia, Canada
https://www.inter-corporate.com/

Re: mod_perl interpreter pool

[Gazzali Jaleel]

On 2/24/2019 1:32 PM, André Warnier (tomcat) wrote:

On 24.02.2019 01:50, Gazzali Jaleel wrote:


On 2/22/2019 2:15 PM, John Dunlap wrote:

The Prefork MPM has the following settings:

 StartServers 5
 MinSpareServers   5
 MaxSpareServers  10
 MaxRequestWorkers 150
 MaxConnectionsPerChild   0


I see these Apache directives but the documentation states that they 
only apply to a

threaded mod_perl/Apache which prefork definitely is not:
PerlInterpStart
PerlInterpMax
PerlInterpMinSpare
PerlInterpMaxSpare
PerlInterpMaxRequests

How does mod_perl allocate interpreters to the prefork worker 
processes? Is there one
perl interpreter for each of preform worker? Is there a pool of perl 
interpreters which
is smaller than the pool of prefork workers? Are there settings for 
configuring the size
of the perl interpreter pool? When a request comes in, does the user 
have to wait for a
perl interpreter process to start or is there already one waiting for 
them?


If you're asking about mod_perl and prefork:

Apache handles child process creation. Each Apache child process loads 
the Perl

interpreter when it starts


Actually, I believe that since this is "prefork", it is the main Apache 
process (which already contains a perl interpreter) which gets "forked" 
(in other words duplicated, as it is) to create a child.  So there is 
not really a perl interpreter "being started" here (at least not in the 
sense of "being loaded" etc), it is already loaded and it is part of 
what is being duplicated.
(For a more detailed and precise explanation and example, see : 
http://perl.apache.org/docs/2.0/user/handlers/server.html)

Correct me if I'm wrong.


That's right, thanks for catching it. Should've said child processes 
will already have the Perl interpreter loaded.




I have no qualms with the rest below, sounds correct to me.

  and the Perl interpreter persists in the process till the
process terminates. So, at any given time, there're as many Perl 
interpreters loaded and
ready as there're Apache processes. When a request comes in, if 
there's an available
Apache process to serve the request, it's served. If not, Apache will 
create a new process

or queue the request to be served when a process becomes available.

With the numbers above, your server is able to handle 150 simultaneous 
requests. If
processes are not busy serving requests, then Apache will kill idle 
processes based on
(Min|Max)SpareServers of 5,10. For an overly simple example, if you 
get 150 requests at
8:30 am,  the server could create 145 processes to meet demand. 
However, if not busy at
8:31 am, when everyone has stepped away for coffee, your process count 
could be down near
10. When the boss comes in at 10am and it's back to work, the server 
will create 140 new

... at 10:01am, it's down to 10 again.

Generally, with mod_perl, you don't want Apache to kill idle processes 
but want them to be
around, ready to handle new requests. For maximum performance,  
(Min|Max)SpareServers
could be as high as your MaxRequestWorkers. Of course, all of this 
depends on your RAM,
CPU utilization etc. and you should be able to find a happy medium as 
you tweak the numbers.




--
John Dunlap
/CTO | Lariat/
/
/
/*Direct:*/
/j...@lariat.co /
/
*Customer Service:*/
877.268.6667
supp...@lariat.co 

Re: mod_perl interpreter pool

[tomcat]

On 24.02.2019 01:50, Gazzali Jaleel wrote:


On 2/22/2019 2:15 PM, John Dunlap wrote:

The Prefork MPM has the following settings:

 StartServers 5
 MinSpareServers   5
 MaxSpareServers  10
 MaxRequestWorkers 150
 MaxConnectionsPerChild   0


I see these Apache directives but the documentation states that they only apply 
to a
threaded mod_perl/Apache which prefork definitely is not:
PerlInterpStart
PerlInterpMax
PerlInterpMinSpare
PerlInterpMaxSpare
PerlInterpMaxRequests

How does mod_perl allocate interpreters to the prefork worker processes? Is 
there one
perl interpreter for each of preform worker? Is there a pool of perl 
interpreters which
is smaller than the pool of prefork workers? Are there settings for configuring 
the size
of the perl interpreter pool? When a request comes in, does the user have to 
wait for a
perl interpreter process to start or is there already one waiting for them?


If you're asking about mod_perl and prefork:

Apache handles child process creation. Each Apache child process loads the Perl
interpreter when it starts


Actually, I believe that since this is "prefork", it is the main Apache process (which 
already contains a perl interpreter) which gets "forked" (in other words duplicated, as it 
is) to create a child.  So there is not really a perl interpreter "being started" here (at 
least not in the sense of "being loaded" etc), it is already loaded and it is part of what 
is being duplicated.
(For a more detailed and precise explanation and example, see : 
http://perl.apache.org/docs/2.0/user/handlers/server.html)

Correct me if I'm wrong.

I have no qualms with the rest below, sounds correct to me.

 and the Perl interpreter persists in the process till the

process terminates. So, at any given time, there're as many Perl interpreters 
loaded and
ready as there're Apache processes. When a request comes in, if there's an 
available
Apache process to serve the request, it's served. If not, Apache will create a 
new process
or queue the request to be served when a process becomes available.

With the numbers above, your server is able to handle 150 simultaneous 
requests. If
processes are not busy serving requests, then Apache will kill idle processes 
based on
(Min|Max)SpareServers of 5,10. For an overly simple example, if you get 150 
requests at
8:30 am,  the server could create 145 processes to meet demand. However, if not 
busy at
8:31 am, when everyone has stepped away for coffee, your process count could be 
down near
10. When the boss comes in at 10am and it's back to work, the server will 
create 140 new
... at 10:01am, it's down to 10 again.

Generally, with mod_perl, you don't want Apache to kill idle processes but want 
them to be
around, ready to handle new requests. For maximum performance,  
(Min|Max)SpareServers
could be as high as your MaxRequestWorkers. Of course, all of this depends on 
your RAM,
CPU utilization etc. and you should be able to find a happy medium as you tweak 
the numbers.



--
John Dunlap
/CTO | Lariat/
/
/
/*Direct:*/
/j...@lariat.co /
/
*Customer Service:*/
877.268.6667
supp...@lariat.co 

Re: mod_perl interpreter pool

[Gazzali Jaleel]

On 2/22/2019 2:15 PM, John Dunlap wrote:

The Prefork MPM has the following settings:

     StartServers 5
     MinSpareServers   5
     MaxSpareServers  10
     MaxRequestWorkers 150
     MaxConnectionsPerChild   0


I see these Apache directives but the documentation states that they 
only apply to a threaded mod_perl/Apache which prefork definitely is not:

PerlInterpStart
PerlInterpMax
PerlInterpMinSpare
PerlInterpMaxSpare
PerlInterpMaxRequests

How does mod_perl allocate interpreters to the prefork worker processes? 
Is there one perl interpreter for each of preform worker? Is there a 
pool of perl interpreters which is smaller than the pool of prefork 
workers? Are there settings for configuring the size of the perl 
interpreter pool? When a request comes in, does the user have to wait 
for a perl interpreter process to start or is there already one waiting 
for them?


If you're asking about mod_perl and prefork:

Apache handles child process creation. Each Apache child process loads 
the Perl interpreter when it starts and the Perl interpreter persists in 
the process till the process terminates. So, at any given time, there're 
as many Perl interpreters loaded and ready as there're Apache processes. 
When a request comes in, if there's an available Apache process to serve 
the request, it's served. If not, Apache will create a new process or 
queue the request to be served when a process becomes available.


With the numbers above, your server is able to handle 150 simultaneous 
requests. If processes are not busy serving requests, then Apache will 
kill idle processes based on (Min|Max)SpareServers of 5,10. For an 
overly simple example, if you get 150 requests at 8:30 am,  the server 
could create 145 processes to meet demand. However, if not busy at 8:31 
am, when everyone has stepped away for coffee, your process count could 
be down near 10. When the boss comes in at 10am and it's back to work, 
the server will create 140 new ... at 10:01am, it's down to 10 again.


Generally, with mod_perl, you don't want Apache to kill idle processes 
but want them to be around, ready to handle new requests. For maximum 
performance,  (Min|Max)SpareServers could be as high as your 
MaxRequestWorkers. Of course, all of this depends on your RAM, CPU 
utilization etc. and you should be able to find a happy medium as you 
tweak the numbers.




--
John Dunlap
/CTO | Lariat/
/
/
/*Direct:*/
/j...@lariat.co /
/
*Customer Service:*/
877.268.6667
supp...@lariat.co 

Re: mod_perl developer wanted

[Rolf Schaufelberger]

I'm the original poster of this thread and I can tell some news.
 
First, because somebody asked , why I'ven;t not just posted the dump file here. 
I've chosen this form to find somebody helping us, since a former posting from 
me to the same issue didn't get any response, so I hoped to get it fixed that 
way. I made these  test some months ago , and this discussion motivated me to 
make a new attempt. 
So, this afternoon I made a new installation , compiled a new Perl with 
mod_perl-2.0.10  installed all my dependencies new from CPAN and still got a 
core dump. Since  due to my own investigations my suspect was File::LibMagic, 
since  it appeared on the top of output from the segfault  ( while this output 
sometimes was visible and sometimes wasn't).  The segfault already happened  
during server startup.  
So I looked at the code from LibMagic.pm and found , that it is using XSLoader  
and calls XSLoader::load during startup. 
With the help of the XSLoader- documentation I changed this  to use DynaLoader 
instead :

So I changed :

use XSLoader;

our $VERSION = '1.15';

XSLoader::load( __PACKAGE__, $VERSION );
use base 'Exporter';

to
 
require DynaLoader;
our @ISA = qw( DynaLoader);
our $VERSION = '1.15';
bootstrap File::LibMagic $VERSION;

and now apache starts without segfault and my application seems to run.  (seems 
 because I've just clicked a bit with no error but didn't  male deeper tests).

So , I can setup my systems to use  this patched version of LibMagic and 
problem solved (more or less). But I'm wondering, that nobody else seems to 
have the same problems. I'll contact the author anyway. 
Does anybody have an idea, why  it doesn't work with XSLoader ? 



> Am 23.09.2017 um 07:30 schrieb Jie Gao :
> 
> * Thorsten Schöning mailto:tschoen...@am-soft.de>> 
> wrote:
> 
>> Date: Fri, 22 Sep 2017 17:08:57 +0200
>> From: Thorsten Schöning 
>> To: "modperl@perl.apache.org" 
>> Subject: Re: mod_perl developer wanted
>> 
>> Guten Tag Rolf Schaufelberger,
>> am Donnerstag, 14. September 2017 um 09:10 schrieben Sie:
>> 
>>> We don't have the skills to debug this, so we are looking for somebody who 
>>> will do this.
>>> We have a virtual machine, ready setup, accessible from outside, so this 
>>> could be done from remote.
>> 
>> Why not additionally post your core dumps and some description of your
>> software or such here? Maybe someone recognizes something you missed
>> or is able to provide some debugging help for others or whatever. Or
>> is it secret for some reason? Doesn't sound like you have anything to
>> loose.
> 
> Exactly. That'd also help people who might potentially want to help gauge the 
> extent of the problem - what they are getting into, before committing to it.
> 
>> On the Bugzilla support mailing list for example, people with core
>> dumps after distro upgrades simply often forgot to delete Bugzilla
>> private packages which are not binary compatible to newer Perls
>> anymore and such things.
> 
> One alternative, which I often do, is to build your own binaries.
> 
> 
> Regards,
> 
> 
> Jie
> 
> 
> 
> 
>> Mit freundlichen Grüßen,
>> 
>> Thorsten Schöning
>> 
>> -- 
>> Thorsten Schöning   E-Mail: thorsten.schoen...@am-soft.de
>> AM-SoFT IT-Systeme  http://www.AM-SoFT.de/
>> 
>> Telefon...05151-  9468- 55
>> Fax...05151-  9468- 88
>> Mobil..0178-8 9468- 04
>> 
>> AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
>> AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow

Mit freundlichen Grüßen
Dipl. Ing. Rolf Schaufelberger
Geschäftsführer 

plusW GmbH
Hauffstr. 28/1
73614 Schorndorf 

T +49 (0)7181 4747305
F +49 (0)7181 4745344
r...@plusw.de
www.plusw.de
 
Sitz der Gesellschaft:
plusW GmbH, Stuttgarterstr. 26, 73635 Rudersberg, Deutschland
Geschäftsführer: Dipl. Ing. Rolf Schaufelberger
Amts- und Registergericht: Stuttgart, HRB 725960
Umsatzsteuer-ID: DE 814 966 811

Re: mod_perl developer wanted

[Jie Gao]

* Thorsten Schöning  wrote:

> Date: Fri, 22 Sep 2017 17:08:57 +0200
> From: Thorsten Schöning 
> To: "modperl@perl.apache.org" 
> Subject: Re: mod_perl developer wanted
> 
> Guten Tag Rolf Schaufelberger,
> am Donnerstag, 14. September 2017 um 09:10 schrieben Sie:
> 
> > We don't have the skills to debug this, so we are looking for somebody who 
> > will do this.
> > We have a virtual machine, ready setup, accessible from outside, so this 
> > could be done from remote.
> 
> Why not additionally post your core dumps and some description of your
> software or such here? Maybe someone recognizes something you missed
> or is able to provide some debugging help for others or whatever. Or
> is it secret for some reason? Doesn't sound like you have anything to
> loose.
 
Exactly. That'd also help people who might potentially want to help gauge the 
extent of the problem - what they are getting into, before committing to it.

> On the Bugzilla support mailing list for example, people with core
> dumps after distro upgrades simply often forgot to delete Bugzilla
> private packages which are not binary compatible to newer Perls
> anymore and such things.
 
One alternative, which I often do, is to build your own binaries.


Regards,


Jie




> Mit freundlichen Grüßen,
> 
> Thorsten Schöning
> 
> -- 
> Thorsten Schöning   E-Mail: thorsten.schoen...@am-soft.de
> AM-SoFT IT-Systeme  http://www.AM-SoFT.de/
> 
> Telefon...05151-  9468- 55
> Fax...05151-  9468- 88
> Mobil..0178-8 9468- 04
> 
> AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
> AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
> 

Re: mod_perl developer wanted

[John Dunlap]

Something similar happened to us when we attempted to upgrade from Debian 7
to Debian 8. Seemingly random core dumps were wreaking havoc in our
production environment. At the time, I posted the dumps here but we never
did find a solution and we were forced to fall back to Debian 7, which is
where we're still at. I'm kinda hoping that the problem will have been
fixed in Debian 9 because, if it hasn't, we'll effectively be trapped on
Debian 7.

On Fri, Sep 22, 2017 at 11:08 AM, Thorsten Schöning 
wrote:

> Guten Tag Rolf Schaufelberger,
> am Donnerstag, 14. September 2017 um 09:10 schrieben Sie:
>
> > We don't have the skills to debug this, so we are looking for somebody
> who will do this.
> > We have a virtual machine, ready setup, accessible from outside, so this
> could be done from remote.
>
> Why not additionally post your core dumps and some description of your
> software or such here? Maybe someone recognizes something you missed
> or is able to provide some debugging help for others or whatever. Or
> is it secret for some reason? Doesn't sound like you have anything to
> loose.
>
> On the Bugzilla support mailing list for example, people with core
> dumps after distro upgrades simply often forgot to delete Bugzilla
> private packages which are not binary compatible to newer Perls
> anymore and such things.
>
> Mit freundlichen Grüßen,
>
> Thorsten Schöning
>
> --
> Thorsten Schöning   E-Mail: thorsten.schoen...@am-soft.de
> AM-SoFT IT-Systeme  http://www.AM-SoFT.de/
>
> Telefon...05151-  9468- 55
> Fax...05151-  9468- 88
> Mobil..0178-8 9468- 04
>
> AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
> AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
>
>


-- 
John Dunlap
*CTO | Lariat *

*Direct:*
*j...@lariat.co *

*Customer Service:*
877.268.6667
supp...@lariat.co

Re: mod_perl developer wanted

[Thorsten Schöning]

Guten Tag Rolf Schaufelberger,
am Donnerstag, 14. September 2017 um 09:10 schrieben Sie:

> We don't have the skills to debug this, so we are looking for somebody who 
> will do this.
> We have a virtual machine, ready setup, accessible from outside, so this 
> could be done from remote.

Why not additionally post your core dumps and some description of your
software or such here? Maybe someone recognizes something you missed
or is able to provide some debugging help for others or whatever. Or
is it secret for some reason? Doesn't sound like you have anything to
loose.

On the Bugzilla support mailing list for example, people with core
dumps after distro upgrades simply often forgot to delete Bugzilla
private packages which are not binary compatible to newer Perls
anymore and such things.

Mit freundlichen Grüßen,

Thorsten Schöning

-- 
Thorsten Schöning   E-Mail: thorsten.schoen...@am-soft.de
AM-SoFT IT-Systeme  http://www.AM-SoFT.de/

Telefon...05151-  9468- 55
Fax...05151-  9468- 88
Mobil..0178-8 9468- 04

AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow

Re: mod_perl and cgi-script handler

[Jie Gao]

HI Andre

I used to use "perl-script", but this time round, performance is not a critical 
factor to consider, but rather the "backward compatibility", so a plain cgi 
script suffices.

Regards,


Jie



> Date: Sun, 11 Jun 2017 11:57:25 +0200
> From: "André Warnier (tomcat)" 
> To: modperl@perl.apache.org
> Subject: Re: mod_perl and cgi-script handler
> User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:38.0) Gecko/20100101
>  Thunderbird/38.5.0
> 
> Addendum :
> 
> This is independent of the other previous explanations.
> 
> If your cgi-bin scripts happen to be written in perl, then you would get a
> rather important *response* performance improvement by using
> 
> 
>   SetHandler perl-script
>   PerlResponseHandler ModPerl::Registry
> ..
> 
> 
> That is because then, the first time your script is called, mod_perl would
> compile it, and save the (pre-)compiled code in memory. And the next time
> your script is called, the Apache-embedded perl interpreter would just run
> the pre-compiled code.
> 
> One drawback is memory : each of the Apache "children" will now store a
> pre-compiled copy of every perl cgi-bin script that has been run since this
> child was started. But if your scripts are run many times, the performance
> improvement is really dramatic.
> 
> 
> On 11.06.2017 11:36, André Warnier (tomcat) wrote:
> >Hi.
> >
> >Now that you mention this, I believe that the original "mistake" in your 
> >configuration
> >was the
> >
> >
> >..
> >SetHandler modperl
> >..
> >
> >
> >and by just taking that line out, you would have the same effect (without 
> >the ).
> >SetHandler is the line which originally overrides the effect of 
> >"ScriptAlias".
> >
> >You do not need "SetHandler modperl" in order to do the authentication via 
> >your module.
> >The "PerlAuthenHandler" is all that is needed.
> >
> >SetHandler applies to the Apache response-generation phase, which comes 
> >later than the AAA
> >phase.
> >
> >To explain this in another way :
> >
> >What you are now doing below is :
> >
> >1) ScriptAlias /cgi-bin/ "/var/www/my-server-name/cgi-bin/"
> >
> >That does the same as :
> >Alias /cgi-bin/ "/var/www/my-server-name/cgi-bin/"
> >plus
> >
> >   SetHandler cgi-script
> >
> >
> >It sets the Apache response-generating module to be mod_cgi, instead of the 
> >default (which
> >serves static pages).
> >See :
> >http://httpd.apache.org/docs/2.4/mod/mod_alias.html#scriptalias
> >http://httpd.apache.org/docs/2.4/mod/mod_cgi.html
> >
> >2) SetHandler modperl
> >
> >This overrides the "cgi-script" response handler which you set above, to set 
> >mod_perl
> >instead.  mod_perl would now expect an additional directive
> >PerlResponseHandler (some perl sub/method).
> >See : http://perl.apache.org/docs/2.0/user/config/config.html#C_SetHandler_
> >
> >3) 
> >   SetHandler cgi-script
> >
> >By doing this, you are resetting the response handler again, from mod_perl 
> >back to
> >cgi-script (mod_cgi).
> >
> >
> >So instead, if you just omit
> >   SetHandler modperl
> >
> >it would be simpler, and just as effective.
> >
> >And if you want even more info about what is happening, see the following :
> >https://perl.apache.org/docs/2.0/user/handlers/http.html
> >(Note : the AAA part there is outdated for Apache 2.4)
> >
> >On 11.06.2017 01:47, Jie Gao wrote:
> >>It seemed "SetHandler" in the mod_perl section overwrote the settings for 
> >>cgi-script.
> >>Adding the following to the directory stanza fixed the problem:
> >>
> >> 
> >> SetHandler cgi-script
> >> 
> >>
> >>..
> >>
> >>Regards,
> >>
> >>
> >>Jie
> >>
> >>
> >>
> >>* Jie Gao  wrote:
> >>
> >>>Date: Fri, 9 Jun 2017 20:35:43 +1000
> >>>From: Jie Gao 
> >>>To: modperl@perl.apache.org
> >>>Subject: mod_perl and cgi-script handler
> >>>User-Agent: Mutt/1.5.24 (2015-08-30)
> >>>
> >>>Hi All
> >>>
> >>>I have run into a problem with CGI under mod_perl, and I can't get my head 
> >>>around it.
> >>>
> >>>I wanted to put a "cgi-bin" directory under my 
> >>>authentication/authorisation 

Re: mod_perl and cgi-script handler

[Jie Gao]

Hi Andre

Yes, you are right: I have removed "SetHandler modperl", which I did not need 
for the response stage, and the FilesMatch container, and things still work!

Thanks very much for your detailed reply.

Regards,


Jie

* André Warnier (tomcat)  wrote:

> Date: Sun, 11 Jun 2017 11:36:48 +0200
> From: "André Warnier (tomcat)" 
> To: modperl@perl.apache.org
> Subject: Re: mod_perl and cgi-script handler
> User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:38.0) Gecko/20100101
>  Thunderbird/38.5.0
> 
> Hi.
> 
> Now that you mention this, I believe that the original "mistake" in your 
> configuration
> was the
> 
> 
> ..
>SetHandler modperl
> ..
> 
> 
> and by just taking that line out, you would have the same effect (without the 
> ).
> SetHandler is the line which originally overrides the effect of "ScriptAlias".
> 
> You do not need "SetHandler modperl" in order to do the authentication via
> your module. The "PerlAuthenHandler" is all that is needed.
> 
> SetHandler applies to the Apache response-generation phase, which comes
> later than the AAA phase.
> 
> To explain this in another way :
> 
> What you are now doing below is :
> 
> 1) ScriptAlias /cgi-bin/ "/var/www/my-server-name/cgi-bin/"
> 
> That does the same as :
> Alias /cgi-bin/ "/var/www/my-server-name/cgi-bin/"
> plus
> 
>   SetHandler cgi-script
> 
> 
> It sets the Apache response-generating module to be mod_cgi, instead of the
> default (which serves static pages).
> See :
> http://httpd.apache.org/docs/2.4/mod/mod_alias.html#scriptalias
> http://httpd.apache.org/docs/2.4/mod/mod_cgi.html
> 
> 2) SetHandler modperl
> 
> This overrides the "cgi-script" response handler which you set above, to set
> mod_perl instead.  mod_perl would now expect an additional directive
> PerlResponseHandler (some perl sub/method).
> See : http://perl.apache.org/docs/2.0/user/config/config.html#C_SetHandler_
> 
> 3) 
>   SetHandler cgi-script
> 
> By doing this, you are resetting the response handler again, from mod_perl
> back to cgi-script (mod_cgi).
> 
> 
> So instead, if you just omit
>   SetHandler modperl
> 
> it would be simpler, and just as effective.
> 
> And if you want even more info about what is happening, see the following :
> https://perl.apache.org/docs/2.0/user/handlers/http.html
> (Note : the AAA part there is outdated for Apache 2.4)
> 
> On 11.06.2017 01:47, Jie Gao wrote:
> >It seemed "SetHandler" in the mod_perl section overwrote the settings for 
> >cgi-script. Adding the following to the directory stanza fixed the problem:
> >
> > 
> > SetHandler cgi-script
> > 
> >
> >..
> >
> >Regards,
> >
> >
> >Jie
> >
> >
> >
> >* Jie Gao  wrote:
> >
> >>Date: Fri, 9 Jun 2017 20:35:43 +1000
> >>From: Jie Gao 
> >>To: modperl@perl.apache.org
> >>Subject: mod_perl and cgi-script handler
> >>User-Agent: Mutt/1.5.24 (2015-08-30)
> >>
> >>Hi All
> >>
> >>I have run into a problem with CGI under mod_perl, and I can't get my head 
> >>around it.
> >>
> >>I wanted to put a "cgi-bin" directory under my authentication/authorisation 
> >>handlers, but while authen/authz works fine (debug showing access granted), 
> >>the directory is in the end not handled by "cgi-script", the default cgid 
> >>content handler, and the text of the cgi script gets displayed instead.
> >>
> >>My configuration is like the following:
> >>
> >>#
> >>
> >>PerlAddAuthzProvider my_User W::W::Authnz->authz
> >>
> >>
> >>...
> >>ScriptAlias /cgi-bin/ "/var/www/my-server-name/cgi-bin/"
> >>
> >>
> >> AllowOverride None
> >>
> >>#PerlOptions +SetupEnv
> >>#Options +ExecCGI
> >>#SetHandler modperl
> >>#PerlAuthenHandler W::W::Authnz->authen
> >>#AuthType mytype
> >>#AuthName 'myname'
> >>#
> >>#Require my_User mylogin
> >>#Require ip 10.65.
> >>#
> >>
> >>
> >>
> >>
> >>#
> >>
> >>If I comment out, as above, all the mod_perl configurations, and then add 
> >>"Require all granted" to the directory stanza, the cgi scripts will run 
> >>normally.
> >>
> >>Any tips/pointers as to where else I should look would be much appreciated.
> >>
> >>Regards,
> >>
> >>
> >>
> >>Jie
> >>
> >
> 

Re: mod_perl and cgi-script handler

[tomcat]

Addendum :

This is independent of the other previous explanations.

If your cgi-bin scripts happen to be written in perl, then you would get a rather 
important *response* performance improvement by using



  SetHandler perl-script
  PerlResponseHandler ModPerl::Registry
..


That is because then, the first time your script is called, mod_perl would compile it, and 
save the (pre-)compiled code in memory. And the next time your script is called, the 
Apache-embedded perl interpreter would just run the pre-compiled code.


One drawback is memory : each of the Apache "children" will now store a pre-compiled copy 
of every perl cgi-bin script that has been run since this child was started. But if your 
scripts are run many times, the performance improvement is really dramatic.



On 11.06.2017 11:36, André Warnier (tomcat) wrote:

Hi.

Now that you mention this, I believe that the original "mistake" in your 
configuration
was the


..
SetHandler modperl
..


and by just taking that line out, you would have the same effect (without the 
).
SetHandler is the line which originally overrides the effect of "ScriptAlias".

You do not need "SetHandler modperl" in order to do the authentication via your 
module.
The "PerlAuthenHandler" is all that is needed.

SetHandler applies to the Apache response-generation phase, which comes later 
than the AAA
phase.

To explain this in another way :

What you are now doing below is :

1) ScriptAlias /cgi-bin/ "/var/www/my-server-name/cgi-bin/"

That does the same as :
Alias /cgi-bin/ "/var/www/my-server-name/cgi-bin/"
plus

   SetHandler cgi-script


It sets the Apache response-generating module to be mod_cgi, instead of the 
default (which
serves static pages).
See :
http://httpd.apache.org/docs/2.4/mod/mod_alias.html#scriptalias
http://httpd.apache.org/docs/2.4/mod/mod_cgi.html

2) SetHandler modperl

This overrides the "cgi-script" response handler which you set above, to set 
mod_perl
instead.  mod_perl would now expect an additional directive
PerlResponseHandler (some perl sub/method).
See : http://perl.apache.org/docs/2.0/user/config/config.html#C_SetHandler_

3) 
   SetHandler cgi-script

By doing this, you are resetting the response handler again, from mod_perl back 
to
cgi-script (mod_cgi).


So instead, if you just omit
   SetHandler modperl

it would be simpler, and just as effective.

And if you want even more info about what is happening, see the following :
https://perl.apache.org/docs/2.0/user/handlers/http.html
(Note : the AAA part there is outdated for Apache 2.4)

On 11.06.2017 01:47, Jie Gao wrote:

It seemed "SetHandler" in the mod_perl section overwrote the settings for 
cgi-script.
Adding the following to the directory stanza fixed the problem:

 
 SetHandler cgi-script
 

..

Regards,


Jie



* Jie Gao  wrote:


Date: Fri, 9 Jun 2017 20:35:43 +1000
From: Jie Gao 
To: modperl@perl.apache.org
Subject: mod_perl and cgi-script handler
User-Agent: Mutt/1.5.24 (2015-08-30)

Hi All

I have run into a problem with CGI under mod_perl, and I can't get my head 
around it.

I wanted to put a "cgi-bin" directory under my authentication/authorisation 
handlers,
but while authen/authz works fine (debug showing access granted), the directory 
is in
the end not handled by "cgi-script", the default cgid content handler, and the 
text of
the cgi script gets displayed instead.

My configuration is like the following:

#

PerlAddAuthzProvider my_User W::W::Authnz->authz


...
ScriptAlias /cgi-bin/ "/var/www/my-server-name/cgi-bin/"


 AllowOverride None

#PerlOptions +SetupEnv
#Options +ExecCGI
#SetHandler modperl
#PerlAuthenHandler W::W::Authnz->authen
#AuthType mytype
#AuthName 'myname'
#
#Require my_User mylogin
#Require ip 10.65.
#




#

If I comment out, as above, all the mod_perl configurations, and then add 
"Require all
granted" to the directory stanza, the cgi scripts will run normally.

Any tips/pointers as to where else I should look would be much appreciated.

Regards,



Jie

Re: mod_perl and cgi-script handler

[tomcat]

Hi.

Now that you mention this, I believe that the original "mistake" in your 
configuration
was the


..
   SetHandler modperl
..


and by just taking that line out, you would have the same effect (without the 
).
SetHandler is the line which originally overrides the effect of "ScriptAlias".

You do not need "SetHandler modperl" in order to do the authentication via your module. 
The "PerlAuthenHandler" is all that is needed.


SetHandler applies to the Apache response-generation phase, which comes later than the AAA 
phase.


To explain this in another way :

What you are now doing below is :

1) ScriptAlias /cgi-bin/ "/var/www/my-server-name/cgi-bin/"

That does the same as :
Alias /cgi-bin/ "/var/www/my-server-name/cgi-bin/"
plus

  SetHandler cgi-script


It sets the Apache response-generating module to be mod_cgi, instead of the default (which 
serves static pages).

See :
http://httpd.apache.org/docs/2.4/mod/mod_alias.html#scriptalias
http://httpd.apache.org/docs/2.4/mod/mod_cgi.html

2) SetHandler modperl

This overrides the "cgi-script" response handler which you set above, to set mod_perl 
instead.  mod_perl would now expect an additional directive

PerlResponseHandler (some perl sub/method).
See : http://perl.apache.org/docs/2.0/user/config/config.html#C_SetHandler_

3) 
  SetHandler cgi-script

By doing this, you are resetting the response handler again, from mod_perl back to 
cgi-script (mod_cgi).



So instead, if you just omit
  SetHandler modperl

it would be simpler, and just as effective.

And if you want even more info about what is happening, see the following :
https://perl.apache.org/docs/2.0/user/handlers/http.html
(Note : the AAA part there is outdated for Apache 2.4)

On 11.06.2017 01:47, Jie Gao wrote:

It seemed "SetHandler" in the mod_perl section overwrote the settings for 
cgi-script. Adding the following to the directory stanza fixed the problem:

 
 SetHandler cgi-script
 

..

Regards,


Jie



* Jie Gao  wrote:


Date: Fri, 9 Jun 2017 20:35:43 +1000
From: Jie Gao 
To: modperl@perl.apache.org
Subject: mod_perl and cgi-script handler
User-Agent: Mutt/1.5.24 (2015-08-30)

Hi All

I have run into a problem with CGI under mod_perl, and I can't get my head 
around it.

I wanted to put a "cgi-bin" directory under my authentication/authorisation handlers, but 
while authen/authz works fine (debug showing access granted), the directory is in the end not 
handled by "cgi-script", the default cgid content handler, and the text of the cgi script 
gets displayed instead.

My configuration is like the following:

#

PerlAddAuthzProvider my_User W::W::Authnz->authz


...
ScriptAlias /cgi-bin/ "/var/www/my-server-name/cgi-bin/"


 AllowOverride None

#PerlOptions +SetupEnv
#Options +ExecCGI
#SetHandler modperl
#PerlAuthenHandler W::W::Authnz->authen
#AuthType mytype
#AuthName 'myname'
#
#Require my_User mylogin
#Require ip 10.65.
#




#

If I comment out, as above, all the mod_perl configurations, and then add "Require 
all granted" to the directory stanza, the cgi scripts will run normally.

Any tips/pointers as to where else I should look would be much appreciated.

Regards,



Jie

Re: mod_perl and cgi-script handler

[Jie Gao]

It seemed "SetHandler" in the mod_perl section overwrote the settings for 
cgi-script. Adding the following to the directory stanza fixed the problem:


SetHandler cgi-script


.

Regards,


Jie



* Jie Gao  wrote:

> Date: Fri, 9 Jun 2017 20:35:43 +1000
> From: Jie Gao 
> To: modperl@perl.apache.org
> Subject: mod_perl and cgi-script handler
> User-Agent: Mutt/1.5.24 (2015-08-30)
> 
> Hi All
> 
> I have run into a problem with CGI under mod_perl, and I can't get my head 
> around it.
> 
> I wanted to put a "cgi-bin" directory under my authentication/authorisation 
> handlers, but while authen/authz works fine (debug showing access granted), 
> the directory is in the end not handled by "cgi-script", the default cgid 
> content handler, and the text of the cgi script gets displayed instead.
> 
> My configuration is like the following:
> 
> #
> 
> PerlAddAuthzProvider my_User W::W::Authnz->authz
> 
> 
> ...
> ScriptAlias /cgi-bin/ "/var/www/my-server-name/cgi-bin/"
> 
> 
> AllowOverride None
> 
> #PerlOptions +SetupEnv
> #Options +ExecCGI
> #SetHandler modperl
> #PerlAuthenHandler W::W::Authnz->authen
> #AuthType mytype
> #AuthName 'myname'
> #
> #Require my_User mylogin
> #Require ip 10.65.
> #
> 
> 
>   
> 
> #
> 
> If I comment out, as above, all the mod_perl configurations, and then add 
> "Require all granted" to the directory stanza, the cgi scripts will run 
> normally.
> 
> Any tips/pointers as to where else I should look would be much appreciated.
> 
> Regards,
> 
> 
> 
> Jie
> 

Re: mod_perl and cgi-script handler

[tomcat]

Hi.

I am using much the same kind of config (Apache 2.4, mod_perl, own AAA module, cgi-bin) in 
multiple places, and have not seen that issue yet. But let me gather some additional info, 
to make sure, and I'll get back here.



On 09.06.2017 12:35, Jie Gao wrote:

Hi All

I have run into a problem with CGI under mod_perl, and I can't get my head 
around it.

I wanted to put a "cgi-bin" directory under my authentication/authorisation handlers, but 
while authen/authz works fine (debug showing access granted), the directory is in the end not 
handled by "cgi-script", the default cgid content handler, and the text of the cgi script 
gets displayed instead.

My configuration is like the following:

#

PerlAddAuthzProvider my_User W::W::Authnz->authz


...
ScriptAlias /cgi-bin/ "/var/www/my-server-name/cgi-bin/"


 AllowOverride None

#PerlOptions +SetupEnv
#Options +ExecCGI
#SetHandler modperl
#PerlAuthenHandler W::W::Authnz->authen
#AuthType mytype
#AuthName 'myname'
#
#Require my_User mylogin
#Require ip 10.65.
#




#

If I comment out, as above, all the mod_perl configurations, and then add "Require 
all granted" to the directory stanza, the cgi scripts will run normally.

Any tips/pointers as to where else I should look would be much appreciated.

Regards,



Jie

Re: mod_perl and utf8 and CGI->param

[Randal L. Schwartz]

> "Peng" == Peng Yonghua  writes:

Peng> And, can I override any method from a class via this way? is this a 
general
Peng> trick? thanks.

Yes, and your downstream will hate you for it.  The ruby people do this
all the time, and it makes their code brittle.  I did this in my app,
and would never think of putting that into the core CGI::Prototype where
this gets used, even though it would solve the problem for everyone.

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
 http://www.stonehenge.com/merlyn/>
Perl/Unix consulting, Technical writing, Comedy, etc. etc.
Still trying to think of something clever for the fourth line of this .sig

Re: mod_perl and utf8 and CGI->param

[Peng Yonghua]

And, can I override any method from a class via this way? is this a 
general trick? thanks.


On 2017/6/2  8:48, Peng Yonghua wrote:

good patch. thanks for sharing.

On 2017/6/1  23:34, Randal L. Schwartz wrote:

I realized that I never posted my ultimate solution.  I monkey patch
CGI.pm:

require CGI;
{
   my $orig = \&CGI::param;
   no warnings 'redefine';
   *CGI::param = sub {
 $CGI::LIST_CONTEXT_WARN = 0; # workaround for backward compatibility
 $CGI::PARAM_UTF8 = 1;
 goto &$orig;
   };
}

And this has been working just fine for both CGI and mod_perl.  Just 
for the

record.

Re: mod_perl and utf8 and CGI->param

[Peng Yonghua]

good patch. thanks for sharing.

On 2017/6/1  23:34, Randal L. Schwartz wrote:

I realized that I never posted my ultimate solution.  I monkey patch
CGI.pm:

require CGI;
{
   my $orig = \&CGI::param;
   no warnings 'redefine';
   *CGI::param = sub {
 $CGI::LIST_CONTEXT_WARN = 0; # workaround for backward compatibility
 $CGI::PARAM_UTF8 = 1;
 goto &$orig;
   };
}

And this has been working just fine for both CGI and mod_perl.  Just for the
record.

Re: mod_perl and utf8 and CGI->param

[Randal L. Schwartz]

> "Randal" == Randal L Schwartz  writes:
Randal> Getting really frustrated with mod_perl2's apparent inability to
Randal> probably read UTF8 input.

Randal> Here's my mod_perl2 setup:

Randal>   Apache 2.2.[something]
Randal>   mod_perl 2.0.7 (or nearly that)
Randal>   ModPerl::Registry
Randal>   Perl "script" with CGI.pm

Randal> Very early in my app:

Randal>   ## ensure utf8 CGI params:
Randal>   $CGI::PARAM_UTF8 = 1;

Randal>   binmode STDIN, ":utf8";
Randal>   binmode STDOUT, ":utf8";
Randal>   binmode STDERR, ":utf8";

Randal> This works fine in CGI mode: when I ask for $foo = $cgi->param('foo'),
Randal> DBI::data_string_desc($foo) shows a UTF8 string with the proper
Randal> discrepency between bytes and chars.

Randal> But when I try to run it under mod_perl, the returned string appears
Randal> to be the raw ascii bytes, and definitely not utf8.  Of course, when I
Randal> store that in the database (using DBD::Pg), the "latin-1" is encoded
Randal> to "utf-8", and I get a bunch of weird chars on the output.

Randal> Has anyone managed to round-trip UTF8 from form to database and back
Randal> using a setup similar to this?

Randal> I suspect part of the problem is this in CGI.pm:

Randal> 'read_from_client' => <<'END_OF_FUNC',
Randal> # Read data from a file handle
Randal> sub read_from_client {
Randal> my($self, $buff, $len, $offset) = @_;
Randal> local $^W=0;# prevent a warning
Randal> return $MOD_PERL
Randal> ? $self->r->read($$buff, $len, $offset)
Randal> : read(\*STDIN, $$buff, $len, $offset);
Randal> }
Randal> END_OF_FUNC

Randal> Since I binmode STDIN, the non-$MOD_PERL works ok here.  What's the
Randal> equivalent of $r->read() that marks the incoming stream as UTF8, so I
Randal> get chars instead of bytes?  Or can I just read(\*STDIN) in mod_perl2
Randal> as well? (I know that was supported at one point...)

I realized that I never posted my ultimate solution.  I monkey patch
CGI.pm:

require CGI;
{
  my $orig = \&CGI::param;
  no warnings 'redefine';
  *CGI::param = sub {
$CGI::LIST_CONTEXT_WARN = 0; # workaround for backward compatibility
$CGI::PARAM_UTF8 = 1;
goto &$orig;
  };
}

And this has been working just fine for both CGI and mod_perl.  Just for the
record.

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
 http://www.stonehenge.com/merlyn/>
Perl/Unix consulting, Technical writing, Comedy, etc. etc.
Still trying to think of something clever for the fourth line of this .sig

Re: mod_perl -> application server

[James Smith]

You can use mod_perl properly and write your self a request handler - 
rather than using CGI scripts which handles the routing for you. I use 
this model exclusively on my servers...


Most of the scripts are converted to action modules, which are 
dynamically compiled by the handler (which acts as a router/controller)


It uses apreq2 (APR) rather than CGI

I think CGI::Application is (or at least was deprecated)


On 2017-04-06 11:05 AM, Tosh Cooey wrote:
Hi, after the recent discussion here about Perl application servers I 
realized that the architecture I designed is probably better suited to 
usage with an application server than mod_perl.






--
The Wellcome Trust Sanger Institute is operated by Genome Research 
Limited, a charity registered in England with number 1021457 and a 
company registered in England with number 2742969, whose registered 
office is 215 Euston Road, London, NW1 2BE. 

Re: mod_perl -> application server

[Randolf Richardson]

Hello Tosh.  I stopped using CGI.pm a very long time ago after 
learning about the apreq2 library which provides access to the 
Apache2::Request module.  Particularly, there is support for CGI 
parameters, including multiple file uploads from the same HTML form, 
and also the Cookie API:


http://search.cpan.org/~isaac/libapreq2-2.13/glue/perl/lib/Apache2/Request.pm

In addition to mod_perl2, you'll also need to install libapreq2.  On 
NetBSD (the server Operating System that I use), the packages and 
pkgin systems both support this very well with Apache HTTPd v2.2 and 
Apache HTTPd v2.4 on all of my production systems.  As I understand 
it, these modules are also supported very well on other flavours of 
Unix and probably most (if not all) distributions of Linux.

Apache2::Request is not a drop-in replacement for CGI.pm (or at 
least it wasn't when I initially switched to Apache2::Request), but 
it does provide the functionality needed to handle HTTP's GET and 
POST methods used with HTML forms in a feature-rich manner with a lot 
of flexibility for handling file uploads.

(I don't know if mod_perl2 provides support for accessing CGI 
parameters without apreq, and I have not looked into it.)

After I first made the change from CGI.pm to using apreq2, I noticed 
that CPU utilization was dramatically lower during peak times for my 
busier web sites, so I felt that this was well worth the effort.

> Hi, after the recent discussion here about Perl application servers I 
> realized that the architecture I designed is probably better suited to 
> usage with an application server than mod_perl.
> 
> The basic structure of my mod_perl web application is:
> 
> *.pl files are handled by ModPerl::Registry
> 
> All *.pl files are structured in the following way:
> 
> #!/usr/bin/perl
> 
> use strict;
> use CGI;
> ...
> 
> &main;
> 
> sub main {
> ...
> }
> 
> 
> 
> I use CGI.pm 99% ONLY for dealing with input, $cgi->param() ... 99% of 
> output is either JSON or Template Toolkit generated HTML.
> 
> Should I be looking at CGI::Application?
> 
> Or CGI::PSGI?
> 
> Or even CGI::Emulate::PSGI ?
> 
> Should I ask this elsewhere?
> 
> Thanks for any advice!
> 
> Tosh
> 
> 
> -- 
> McIntosh Cooey - Twelve Hundred Group LLC - http://www.1200group.com/


Randolf Richardson - rand...@inter-corporate.com
Inter-Corporate Computer & Network Services, Inc.
Beautiful British Columbia, Canada
http://www.inter-corporate.com/

Re: mod_perl Website Hosting

[jniederberger]

Thanks, we are not just starting out;
we've been on dedicated
servers at Datapipe for years.
Been using FreeBSD but a change
to some other unix shouldn't be a huge
problem. (Or am I too naïve?)

Just want to know where else are
options.

Thanks again,
Joe N


-Original Message- 
From: Vincent Veyron

Sent: Thursday, March 09, 2017 11:04 AM
To: jniederber...@comcast.net
Cc: modperl@perl.apache.org
Subject: Re: mod_perl Website Hosting

On Sun, 5 Mar 2017 12:40:10 -0500
 wrote:


Just trying to update my knowledge about
website hosting services.
Can anyone recommend hosting companies
that have a good track record of hosting mod_perl
applications?


I'm late on this but As Randolf said, your best bet is probably a dedicated 
server. I've been using low end dedicated servers from online.net and 
kimsufi.com at 10.00 euros/month for years, no problem at all


I even see an offer at 4.99€/month now :

https://www.kimsufi.com/fr/serveurs.xml



--
Bien à vous, Vincent Veyron

https://compta.libremen.com
Logiciel de comptabilité, libre 

Re: mod_perl Website Hosting

[jniederberger]

Hmm, strangely I missed this the first time around.
I wonder how many other responses to my inquiry
I've missed? I only saw two responses myself.

Cheers,
Joe N

-Original Message- 
From: Paul Johnson

Sent: Thursday, March 09, 2017 11:22 AM
To: James Smith
Cc: modperl@perl.apache.org
Subject: Re: mod_perl Website Hosting

On Thu, Mar 09, 2017 at 04:10:40PM +, James Smith wrote:
As I want to stay in the UK - I've been using bigV.io services from 
bytemark
- slighlty more expensive - and you have to set up from scratch - but 
really
nice VMs and not difficult to set-up - and I get to set them up exactly as 
I

want them


And they very generously provide free hosting for metacpan.org and
cpancover.com.  So if you want to go that route and feel like saying
thanks, follow the link from one of those sites.

--
Paul Johnson - p...@pjcj.net
http://www.pjcj.net 

Re: mod_perl Website Hosting

[Paul Johnson]

On Thu, Mar 09, 2017 at 04:10:40PM +, James Smith wrote:
> As I want to stay in the UK - I've been using bigV.io services from bytemark
> - slighlty more expensive - and you have to set up from scratch - but really
> nice VMs and not difficult to set-up - and I get to set them up exactly as I
> want them

And they very generously provide free hosting for metacpan.org and
cpancover.com.  So if you want to go that route and feel like saying
thanks, follow the link from one of those sites.

-- 
Paul Johnson - p...@pjcj.net
http://www.pjcj.net

Re: mod_perl Website Hosting

[James Smith]

As I want to stay in the UK - I've been using bigV.io services from 
bytemark - slighlty more expensive - and you have to set up from scratch 
- but really nice VMs and not difficult to set-up - and I get to set 
them up exactly as I want them



On 2017-03-09 04:04 PM, Vincent Veyron wrote:

On Sun, 5 Mar 2017 12:40:10 -0500
 wrote:


Just trying to update my knowledge about
website hosting services.
Can anyone recommend hosting companies
that have a good track record of hosting mod_perl
applications?

I'm late on this but As Randolf said, your best bet is probably a dedicated 
server. I've been using low end dedicated servers from online.net and 
kimsufi.com at 10.00 euros/month for years, no problem at all

I even see an offer at 4.99€/month now :

https://www.kimsufi.com/fr/serveurs.xml







--
The Wellcome Trust Sanger Institute is operated by Genome Research 
Limited, a charity registered in England with number 1021457 and a 
company registered in England with number 2742969, whose registered 
office is 215 Euston Road, London, NW1 2BE. 

Re: mod_perl Website Hosting

[Vincent Veyron]

On Sun, 5 Mar 2017 12:40:10 -0500
 wrote:

> Just trying to update my knowledge about 
> website hosting services.
> Can anyone recommend hosting companies
> that have a good track record of hosting mod_perl
> applications?

I'm late on this but As Randolf said, your best bet is probably a dedicated 
server. I've been using low end dedicated servers from online.net and 
kimsufi.com at 10.00 euros/month for years, no problem at all

I even see an offer at 4.99€/month now :

https://www.kimsufi.com/fr/serveurs.xml



-- 
Bien à vous, Vincent Veyron 

https://compta.libremen.com
Logiciel de comptabilité, libre

Re: mod_perl Website Hosting

[jniederberger]

Thanks to all that replied. 

Joe N


From: jniederber...@comcast.net 
Sent: Friday, March 03, 2017 4:25 PM
To: modperl@perl.apache.org 
Subject: mod_perl Website Hosting

Hello all,
Just trying to update my knowledge about 
website hosting services.
Can anyone recommend hosting companies
that have a good track record of hosting mod_perl
applications?
The sites we build are not high-volume sites,
they are school websites, municipalities, small
non-profits and small business.
Any recommendations would be greatly
appreciated.
Thank you all,
Joe N

Re: mod_perl Website Hosting

[Randolf Richardson]

> Hello all,
> Just trying to update my knowledge about 
> website hosting services.
> Can anyone recommend hosting companies
> that have a good track record of hosting mod_perl
> applications?

I haven't found much that is secure in a shared server environment, 
so I run my own servers that all run mod_perl2.  The web site hosting 
services I provide for clients are strictly for static HTML web sites 
(due to security reasons in that the server-side code has too much 
access to the system), so the additional hosting options are more 
expensive as a result -- an isolated server (or servers), or a 
virtualized server (nearly all my clients chose the former option).

The big concern will be security.  If server-side code isn't 
restricted or isolated properly (on many hosting systems I've seen it 
isn't), then another user on the system could modify your sites, or 
cause other problems (either intentionally or unintentionally).

Another problem I've encountered is that updates sometimes break 
things, and especially in shared environments that can be more common 
since there is often a need for a wider diversity of libraries, 
modules, etc.  Ideally the updates should be run in test environments 
first, but I only know of a few people who practice this diligently.

I mention these points to give you some ideas about what to consider 
(e.g., isolation) when selecting such a service.

> The sites we build are not high-volume sites,
> they are school websites, municipalities, small
> non-profits and small business.

Volume usually isn't the problem, but transport speed can be if it's 
very slow and you need to serve large documents (e.g., PDFs that are 
hundreds of megabites in size).

An important factor is whether the system can work consistently, and 
it should be tested under heavy load to ensure consistency in the 
event that high volume comes unexpectedly (e.g., the web site is 
featured in the news, or someone redirects traffic from a busy web 
site to yours, etc.).

> Any recommendations would be greatly
> appreciated.
> Thank you all,
> Joe N

Randolf Richardson - rand...@inter-corporate.com
Inter-Corporate Computer & Network Services, Inc.
Beautiful British Columbia, Canada
http://www.inter-corporate.com/

Re: mod_perl Silent Failure, Very Mysterious

[Jie Gao]

Hi Will

I can't put my finger on it, but B::Hooks::OP was last released on 11 Sept 
2011, quite a while ago, and there could be a problem with recent versions of 
perl.


Regards,

Jie 

* William N. Braswell, Jr.  wrote:

> Date: Tue, 22 Nov 2016 23:14:11 -0600
> From: "William N. Braswell, Jr." 
> To: Jie Gao 
> CC: modperl@perl.apache.org
> Subject: Re: mod_perl Silent Failure, Very Mysterious
> 
> Hi Jie,
> If I temporarily disable B::Hooks::OP::Check, as shown below, then it
> tells me it was included from Devel::Declare, which was in turn
> (indireclty) included from Method::Signatures::Simple.
> I am not the author of either Catalyst or ShinyCMS, so unfortunately I
> don't know any more in-depth details off the top of my head.
> Does that answer your question?
> Thanks,~ Will
> wbraswell@cloud-comp0-00:~$ pm_location.sh
> B::Hooks::OP::Check/home/wbraswell/perl5/lib/perl5/x86_64-linux-gnu-thread-multi/B/Hooks/OP/Check.pm
> wbraswell@cloud-comp0-00:~$ mv
> /home/wbraswell/perl5/lib/perl5/x86_64-linux-gnu-thread-multi/B/Hooks/OP/Check.pm
> /home/wbraswell/perl5/lib/perl5/x86_64-linux-gnu-thread-multi/B/Hooks/OP/Check.pm.DISABLED
> wbraswell@cloud-comp0-00:~/public_html/cloud-comp0-00.autoparallel.com-latest$
> perl -e 'use ShinyCMS;'Can't locate B/Hooks/OP/Check.pm in @INC (you
> may need to install the B::Hooks::OP::Check module) (@INC contains
> ) at
> /home/wbraswell/perl5/lib/perl5/x86_64-linux-gnu-thread-multi/Devel/Declare.pm
> line 18.BEGIN failed--compilation aborted at
> /home/wbraswell/perl5/lib/perl5/x86_64-linux-gnu-thread-multi/Devel/Declare.pm
> line 18.Compilation failed in require at
> /home/wbraswell/perl5/lib/perl5/x86_64-linux-gnu-thread-multi/Devel/Declare/Context/Simple.pm
> line 5.BEGIN failed--compilation aborted at
> /home/wbraswell/perl5/lib/perl5/x86_64-linux-gnu-thread-multi/Devel/Declare/Context/Simple.pm
> line 5.Compilation failed in require at /usr/share/perl/5.22/base.pm
> line 97. ...propagated at /usr/share/perl/5.22/base.pm line 106.BEGIN
> failed--compilation aborted at
> /home/wbraswell/perl5/lib/perl5/x86_64-linux-gnu-thread-multi/Devel/Declare/MethodInstaller/Simple.pm
> line 3.Compilation failed in require at /usr/share/perl/5.22/base.pm
> line 97. ...propagated at /usr/share/perl/5.22/base.pm line 106.BEGIN
> failed--compilation aborted at
> /home/wbraswell/perl5/lib/perl5/Method/Signatures/Simple.pm line
> 19.Compilation failed in require at blib/lib/ShinyCMS.pm line 21.BEGIN
> failed--compilation aborted at blib/lib/ShinyCMS.pm line
> 21.Compilation failed in require at -e line 1.BEGIN
> failed--compilation aborted at -e line 1.
> On 11/22/2016 at 11:03 PM, "Jie Gao"  wrote:Hi William
> 
> Where excatly is B::Hooks::OP::Check required / its Check.xs called?
> Regards,
> Jie 
> 
> * William N. Braswell, Jr.  wrote:
> 
> > Date: Tue, 22 Nov 2016 06:04:36 -0600
> > From: "William N. Braswell, Jr." 
> > To: Jie Gao 
> > CC: modperl@perl.apache.org
> > Subject: RE: mod_perl Silent Failure, Very Mysterious
> > 
> > Hello Again Jie,
> > I have run the modperl_testreport.pl script per your direction, and
> > have attached the output file.
> > Also, I have posted this as a mod_perl issue:
> > 
> > https://rt.cpan.org/Ticket/Display.html?id=118900
> > I am attempting to run an already-bug-free Catalyst application
> under
> > mod_perl, which should work just fine but instead gives a segfault
> in
> > the Check.xs file.
> > The name of the Catalyst application is ShinyCMS, it works just fine
> > using the PSGI stand-alone testing web server as well as fastcgi,
> and
> > mod_perl is the only option which causes a segfault.  I must have
> > mod_perl support for my specific use of ShinyCMS, so I really really
> > need to fix this segfault and get Shiny working under mod_perl. 
> Yes,
> > Shiny is specifically designed to work with mod_perl, as are most
> > Catalyst apps.  In fact, my simple ">" print statements in
> ShinyCMS.pm
> > show that Shiny is totally loading and returning control back to
> > Apache (or mod_perl?) before the actual segfault occurs.
> > My system info:
> > $ apache2 -vServer version: Apache/2.4.18 (Ubuntu)Server built:  
> > 2016-07-14T12:32:26
> > $ perl -vThis is perl 5, version 22, subversion 1 (v5.22.1) built
> for
> > x86_64-linux-gnu-thread-multi(with 58 registered patches, see perl
> -V
> > for more detail)
> > $ pm_version.pl mod_perl2$mod_perl2::VERSION = 2.09
> > $ pm_version.pl B::Hooks::OP::Check$B::Hooks::OP::Check::VERSION =
> > 0.19
> > $ cat /etc/issueUbuntu 16.04.1 LTS
> > I have 

Re: mod_perl Silent Failure, Very Mysterious

[William N. Braswell, Jr.]

Hi Jie,
If I temporarily disable B::Hooks::OP::Check, as shown below, then it
tells me it was included from Devel::Declare, which was in turn
(indireclty) included from Method::Signatures::Simple.
I am not the author of either Catalyst or ShinyCMS, so unfortunately I
don't know any more in-depth details off the top of my head.
Does that answer your question?
Thanks,~ Will
wbraswell@cloud-comp0-00:~$ pm_location.sh
B::Hooks::OP::Check/home/wbraswell/perl5/lib/perl5/x86_64-linux-gnu-thread-multi/B/Hooks/OP/Check.pm
wbraswell@cloud-comp0-00:~$ mv
/home/wbraswell/perl5/lib/perl5/x86_64-linux-gnu-thread-multi/B/Hooks/OP/Check.pm
/home/wbraswell/perl5/lib/perl5/x86_64-linux-gnu-thread-multi/B/Hooks/OP/Check.pm.DISABLED
wbraswell@cloud-comp0-00:~/public_html/cloud-comp0-00.autoparallel.com-latest$
perl -e 'use ShinyCMS;'Can't locate B/Hooks/OP/Check.pm in @INC (you
may need to install the B::Hooks::OP::Check module) (@INC contains
) at
/home/wbraswell/perl5/lib/perl5/x86_64-linux-gnu-thread-multi/Devel/Declare.pm
line 18.BEGIN failed--compilation aborted at
/home/wbraswell/perl5/lib/perl5/x86_64-linux-gnu-thread-multi/Devel/Declare.pm
line 18.Compilation failed in require at
/home/wbraswell/perl5/lib/perl5/x86_64-linux-gnu-thread-multi/Devel/Declare/Context/Simple.pm
line 5.BEGIN failed--compilation aborted at
/home/wbraswell/perl5/lib/perl5/x86_64-linux-gnu-thread-multi/Devel/Declare/Context/Simple.pm
line 5.Compilation failed in require at /usr/share/perl/5.22/base.pm
line 97. ...propagated at /usr/share/perl/5.22/base.pm line 106.BEGIN
failed--compilation aborted at
/home/wbraswell/perl5/lib/perl5/x86_64-linux-gnu-thread-multi/Devel/Declare/MethodInstaller/Simple.pm
line 3.Compilation failed in require at /usr/share/perl/5.22/base.pm
line 97. ...propagated at /usr/share/perl/5.22/base.pm line 106.BEGIN
failed--compilation aborted at
/home/wbraswell/perl5/lib/perl5/Method/Signatures/Simple.pm line
19.Compilation failed in require at blib/lib/ShinyCMS.pm line 21.BEGIN
failed--compilation aborted at blib/lib/ShinyCMS.pm line
21.Compilation failed in require at -e line 1.BEGIN
failed--compilation aborted at -e line 1.
On 11/22/2016 at 11:03 PM, "Jie Gao"  wrote:Hi William

Where excatly is B::Hooks::OP::Check required / its Check.xs called?
Regards,
Jie 

* William N. Braswell, Jr.  wrote:

> Date: Tue, 22 Nov 2016 06:04:36 -0600
> From: "William N. Braswell, Jr." 
> To: Jie Gao 
> CC: modperl@perl.apache.org
> Subject: RE: mod_perl Silent Failure, Very Mysterious
> 
> Hello Again Jie,
> I have run the modperl_testreport.pl script per your direction, and
> have attached the output file.
> Also, I have posted this as a mod_perl issue:
> 
> https://rt.cpan.org/Ticket/Display.html?id=118900
> I am attempting to run an already-bug-free Catalyst application
under
> mod_perl, which should work just fine but instead gives a segfault
in
> the Check.xs file.
> The name of the Catalyst application is ShinyCMS, it works just fine
> using the PSGI stand-alone testing web server as well as fastcgi,
and
> mod_perl is the only option which causes a segfault.  I must have
> mod_perl support for my specific use of ShinyCMS, so I really really
> need to fix this segfault and get Shiny working under mod_perl. 
Yes,
> Shiny is specifically designed to work with mod_perl, as are most
> Catalyst apps.  In fact, my simple ">" print statements in
ShinyCMS.pm
> show that Shiny is totally loading and returning control back to
> Apache (or mod_perl?) before the actual segfault occurs.
> My system info:
> $ apache2 -vServer version: Apache/2.4.18 (Ubuntu)Server built:  
> 2016-07-14T12:32:26
> $ perl -vThis is perl 5, version 22, subversion 1 (v5.22.1) built
for
> x86_64-linux-gnu-thread-multi(with 58 registered patches, see perl
-V
> for more detail)
> $ pm_version.pl mod_perl2$mod_perl2::VERSION = 2.09
> $ pm_version.pl B::Hooks::OP::Check$B::Hooks::OP::Check::VERSION =
> 0.19
> $ cat /etc/issueUbuntu 16.04.1 LTS
> I have spent the last week trying all of the following and more, but
> the segfault persists:
> 1.  manually-compiled perl v5.22.1 & mod_perl2 v2.09 w/out
> threads2.  mod_perl2 back to v2.053.  B::Hooks::OP::Check back
to
> v0.17 (maybe earlier)4.  move all possible 'use' statements to be
> called as early as possible in Shiny_dependencies.pm
> I also tried Apache v2.2 & mod_perl2 v2.08 & Perl v5.18.2 in
> Ubuntu v14.04, it did not segfault but instead it served up totally
> blank pages with 0 bytes of data.  I have not dug deeper because I
use
> Ubuntu v16.04 in production and I figure it is harder to debug w/out
> an actual segfault to start from.
> I have set up SSH access on a cloud server so you can see and debug
> the segfault directly, all 3 of the usernames below are set as
sudoers
>

Re: mod_perl Silent Failure, Very Mysterious

[Jie Gao]

Hi William

Where excatly is B::Hooks::OP::Check required / its Check.xs called?


Regards,


Jie 

* William N. Braswell, Jr.  wrote:

> Date: Tue, 22 Nov 2016 06:04:36 -0600
> From: "William N. Braswell, Jr." 
> To: Jie Gao 
> CC: modperl@perl.apache.org
> Subject: RE: mod_perl Silent Failure, Very Mysterious
> 
> Hello Again Jie,
> I have run the modperl_testreport.pl script per your direction, and
> have attached the output file.
> Also, I have posted this as a mod_perl issue:
> 
> https://rt.cpan.org/Ticket/Display.html?id=118900
> I am attempting to run an already-bug-free Catalyst application under
> mod_perl, which should work just fine but instead gives a segfault in
> the Check.xs file.
> The name of the Catalyst application is ShinyCMS, it works just fine
> using the PSGI stand-alone testing web server as well as fastcgi, and
> mod_perl is the only option which causes a segfault.  I must have
> mod_perl support for my specific use of ShinyCMS, so I really really
> need to fix this segfault and get Shiny working under mod_perl.  Yes,
> Shiny is specifically designed to work with mod_perl, as are most
> Catalyst apps.  In fact, my simple ">" print statements in ShinyCMS.pm
> show that Shiny is totally loading and returning control back to
> Apache (or mod_perl?) before the actual segfault occurs.
> My system info:
> $ apache2 -vServer version: Apache/2.4.18 (Ubuntu)Server built:  
> 2016-07-14T12:32:26
> $ perl -vThis is perl 5, version 22, subversion 1 (v5.22.1) built for
> x86_64-linux-gnu-thread-multi(with 58 registered patches, see perl -V
> for more detail)
> $ pm_version.pl mod_perl2$mod_perl2::VERSION = 2.09
> $ pm_version.pl B::Hooks::OP::Check$B::Hooks::OP::Check::VERSION =
> 0.19
> $ cat /etc/issueUbuntu 16.04.1 LTS
> I have spent the last week trying all of the following and more, but
> the segfault persists:
> 1.  manually-compiled perl v5.22.1 & mod_perl2 v2.09 w/out
> threads2.  mod_perl2 back to v2.053.  B::Hooks::OP::Check back to
> v0.17 (maybe earlier)4.  move all possible 'use' statements to be
> called as early as possible in Shiny_dependencies.pm
> I also tried Apache v2.2 & mod_perl2 v2.08 & Perl v5.18.2 in
> Ubuntu v14.04, it did not segfault but instead it served up totally
> blank pages with 0 bytes of data.  I have not dug deeper because I use
> Ubuntu v16.04 in production and I figure it is harder to debug w/out
> an actual segfault to start from.
> I have set up SSH access on a cloud server so you can see and debug
> the segfault directly, all 3 of the usernames below are set as sudoers
> so please wield your root powers with caution:
> HOSTNAME: cloud-comp0-00.autoparallel.comHOST IP: 
> 64.137.255.53USERNAME: shay OR fmoyer OR jgao OR modperl_teamPASSWORD:
> check your CPAN e-mail address
> Pertinent paths:
> /home/wbraswell/public_html/cloud-comp0-00.autoparallel.com-latest/etc/apache2/sites-available/cloud-comp0-00.autoparallel.com.conf
> Here is an example gdb showing Check.xs as the likely culprit,
> starting with `sudo` and then `source` to load Apache env vars:
> [[[ BEGIN GDB SESSION ]]]
> zefram@cloud-comp0-00:/$ sudo -i...root@cloud-comp0-00:~# source
> /etc/apache2/envvarsroot@cloud-comp0-00:~# gdb
> /usr/sbin/apache2...Reading symbols from /usr/sbin/apache2...(no
> debugging symbols found)...done.
> (gdb) run -k start -XStarting program: /usr/sbin/apache2 -k start
> -X[Thread debugging using libthread_db enabled]Using host libthread_db
> library "/lib/x86_64-linux-gnu/libthread_db.so.1".>: top of
> ShinyCMS.pm>: in ShinyCMS.pm, about to use Moose>: in ShinyCMS.pm,
> about to use Catalyst::Runtime>: in ShinyCMS.pm, about to use
> Catalyst>: in ShinyCMS.pm, about to use CatalystX::RoleApplicator>: in
> ShinyCMS.pm, about to use Method::Signatures::Simple>: in ShinyCMS.pm,
> about to call config()>: in ShinyCMS.pm, have __PACKAGE__ = ShinyCMS>:
> in ShinyCMS.pm, about to call setup()...>: in ShinyCMS.pm, returned
> from setup()>: in ShinyCMS.pm, about to return 1
> Program received signal SIGSEGV, Segmentation fault.0x7fffebabcb10
> in ?? ()(gdb) bt#0  0x7fffebabcb10 in ?? ()#1  0x73e5302b
> in Perl_newUNOP (my_perl=my_perl@entry=0x577ddde0,
> type=type@entry=17, flags=, flags@entry=8192, first=0x562141b8) at
> op.c:4811#2  0x73e54a1d in Perl_newCVREF
> (my_perl=my_perl@entry=0x577ddde0, flags=flags@entry=8192, o=) at
> op.c:9367#3  0x73e8b686 in Perl_yylex
> (my_perl=my_perl@entry=0x577ddde0) at toke.c:6693#4 
> 0x73e97228 in Perl_yyparse
> (my_perl=my_perl@entry=0x577ddde0, gramtype=gramtype@entry=258) at
> perly.c:322...#44 0x5558709f in main ()

RE: mod_perl Silent Failure, Very Mysterious

[William N. Braswell, Jr.]

h file or directory.
(gdb) watch -l PL_check[17]Hardware watchpoint 3: -location
PL_check[17]
(gdb) continueContinuing.
Hardware watchpoint 3: -location PL_check[17]
Old value = (OP *(*)(PerlInterpreter *, OP *)) 0x73e4d9e0 New
value = (OP *(*)(PerlInterpreter *, OP *)) 0x7fffebabcb10
0x7fffebabcd0e in hook_op_check (type=type@entry=OP_RV2CV,
cb=cb@entry=0x7fffeb8b6d30 , user_data=user_data@entry=0x0) at
Check.xs:  PL_check[type] = check_cb;
(gdb) info threads  Id   Target Id Frame * 1Thread
0x77fe2780 (LWP 6196) "/usr/sbin/apach" 0x7fffebabcd0e in
hook_op_check (type=type@entry=OP_RV2CV, cb=cb@entry=0x7fffeb8b6d30 ,
user_data=user_data@entry=0x0)at Check.xs:66
(gdb) info sourceCurrent source file is Check.xsCompilation directory
is
/home/wbraswell/.cpanm/work/1479735542.24787/B-Hooks-OP-Check-0.19Located
in
/home/wbraswell/.cpanm/work/1479735542.24787/B-Hooks-OP-Check-0.19/Check.xsContains
106 lines.Source language is c.Producer is GNU C11 5.4.0 20160609
-mtune=generic -march=x86-64 -g -O2 -fwrapv -fno-strict-aliasing -fPIC
-fstack-protector-strong.Compiled with DWARF 2 debugging format.Does
not include preprocessor macro info.
(gdb) continueContinuing.>: top of ShinyCMS.pm>: in ShinyCMS.pm, about
to use Moose>: in ShinyCMS.pm, about to use Catalyst::Runtime>: in
ShinyCMS.pm, about to use Catalyst>: in ShinyCMS.pm, about to use
CatalystX::RoleApplicator>: in ShinyCMS.pm, about to use
Method::Signatures::Simple>: in ShinyCMS.pm, about to call config()>:
in ShinyCMS.pm, have __PACKAGE__ = ShinyCMS>: in ShinyCMS.pm, about to
call setup()...>: in ShinyCMS.pm, returned from setup()>: in
ShinyCMS.pm, about to return 1
...
Program received signal SIGSEGV, Segmentation fault.0x7fffebabcb10
in ?? ()(gdb) bt#0  0x7fffebabcb10 in ?? ()#1  0x73e5302b
in Perl_newUNOP (my_perl=my_perl@entry=0x59dd8ed0,
type=type@entry=17, flags=, flags@entry=8192, first=0x5824eb98) at
op.c:4811#2  0x73e54a1d in Perl_newCVREF
(my_perl=my_perl@entry=0x59dd8ed0, flags=flags@entry=8192, o=) at
op.c:9367...#44 0x5558709f in main ()
(gdb) print PL_check[17]$1 = (Perl_check_t) 0x7fffebabcb10
(gdb) quit
[[[ END GDB SESSION ]]]
I have attached the unabbreviated gdb session and the system info in
text files, for your reference.
I am anxious (near desperate) to get this bug fixed so that I can move
forward with my work.  I will eagerly assist in any way I can, please
just let me know what I should do and I will do it!
Thanks so much for your help.
Perling,~ Will

On 11/16/2016 at 3:17 AM, "Jie Gao"  wrote: For the completeness
of issue reporting, please run the following script and post the
output:
 #!/usr/bin/perl
 use strict;
 use warnings FATAL => 'all';
 use ModPerl::TestReport;
 ModPerl::TestReport->new(@ARGV)->run;
 Jie
---------
 From: William N. Braswell, Jr. [william.brasw...@autoparallel.com]
 Sent: Tuesday, November 15, 2016 8:01 PM
 To: Jie Gao
 Cc: modperl@perl.apache.org
 Subject: Re: mod_perl Silent Failure, Very Mysterious
Hello Jie & Friends, 
  I got the core dump out of gdb and also some hopefully-helpful
output. 
  Here is the output from gdb (not the core dump which is binary of
course): 
  http://hastebin.com/okaxacuriq.scala
 Then again maybe we have a problem because I'm missing debugging
symbols inside /usr/sbin/apache2?
 _Program received signal SIGSEGV, Segmentation fault.   
0x7fffeed67a00 in ?? ()_
 Note the _??_ part in the output above... 
  Where do I go from here? 
  Thanks, ~ Will 
 On 11/15/2016 at 12:14 AM, "William N. Braswell, Jr."  wrote:   Hi
Jie, 
  I have captured the output of `strace -f /usr/sbin/apache2 -e trace8
-k start`: 
  http://hastebin.com/unupocozop.pl 
  Looks like it is dying with a segfault, but I'm not sure what is
causing this??? 
  Thanks so much for your help!!!  :-) 
  ~ Will 
  [[[ BEGIN PASTE SNIPPET ]]] 
   [pid  6550] stat("blib/lib/DynaLoader.pmc", 0x7ffdda87f280) = -1
ENOENT (No such file or directory) [pid  6550]
stat("blib/lib/DynaLoader.pm", 0x7ffdda87f1b0) = -1 ENOENT (No such
file or directory) [pid  6550] stat("/etc/perl/DynaLoader.pmc",
0x7ffdda87f280) = -1 ENOENT (No such file or directory) [pid  6550]
stat("/etc/perl/DynaLoader.pm", 0x7ffdda87f1b0) = -1 ENOENT (No such
file or directory) [pid  6550]
stat("/usr/local/lib/x86_64-linux-gnu/perl/5.22.1/DynaLoader.pmc",
0x7ffdda87f280) = -1 ENOENT (No such file or directory) [pid  6550]
stat("/usr/local/lib/x86_64-linux-gnu/perl/5.22.1/DynaLoader.pm",
0x7ffdda87f1b0) = -1 ENOENT (No such file or directory) [pid  6550]
stat("/usr/local/share/perl/5.22.1/DynaLoader.pmc", 0x7ffdda87f280) =
-1 ENOENT (No such file or directory) [pid  6550]
stat("/usr/local/share/perl/5.22.1/DynaLoader.pm", 0x7ffdda87f1b0) =
-1 ENOENT (No such file or di

RE: mod_perl Silent Failure, Very Mysterious

[Jie Gao]

For the completeness of issue reporting, please run the following script and 
post the output:


#!/usr/bin/perl
use strict;
use warnings FATAL => 'all';

use ModPerl::TestReport;
ModPerl::TestReport->new(@ARGV)->run;



Jie

From: William N. Braswell, Jr. [william.brasw...@autoparallel.com]
Sent: Tuesday, November 15, 2016 8:01 PM
To: Jie Gao
Cc: modperl@perl.apache.org
Subject: Re: mod_perl Silent Failure, Very Mysterious

Hello Jie & Friends,

I got the core dump out of gdb and also some hopefully-helpful output.

Here is the output from gdb (not the core dump which is binary of course):

http://hastebin.com/okaxacuriq.scala

Then again maybe we have a problem because I'm missing debugging symbols inside 
/usr/sbin/apache2?

Program received signal SIGSEGV, Segmentation fault.0x7fffeed67a00 in 
?? ()

Note the ?? part in the output above...

Where do I go from here?

Thanks,
~ Will


On 11/15/2016 at 12:14 AM, "William N. Braswell, Jr." 
 wrote:
Hi Jie,

I have captured the output of `strace -f /usr/sbin/apache2 -e trace8 -k start`:

http://hastebin.com/unupocozop.pl

Looks like it is dying with a segfault, but I'm not sure what is causing this???

Thanks so much for your help!!!  :-)

~ Will


[[[ BEGIN PASTE SNIPPET ]]]

[pid  6550] stat("blib/lib/DynaLoader.pmc", 0x7ffdda87f280) = -1 ENOENT (No 
such file or directory)
[pid  6550] stat("blib/lib/DynaLoader.pm", 0x7ffdda87f1b0) = -1 ENOENT (No such 
file or directory)
[pid  6550] stat("/etc/perl/DynaLoader.pmc", 0x7ffdda87f280) = -1 ENOENT (No 
such file or directory)
[pid  6550] stat("/etc/perl/DynaLoader.pm", 0x7ffdda87f1b0) = -1 ENOENT (No 
such file or directory)
[pid  6550] stat("/usr/local/lib/x86_64-linux-gnu/perl/5.22.1/DynaLoader.pmc", 
0x7ffdda87f280) = -1 ENOENT (No such file or directory)
[pid  6550] stat("/usr/local/lib/x86_64-linux-gnu/perl/5.22.1/DynaLoader.pm", 
0x7ffdda87f1b0) = -1 ENOENT (No such file or directory)
[pid  6550] stat("/usr/local/share/perl/5.22.1/DynaLoader.pmc", 0x7ffdda87f280) 
= -1 ENOENT (No such file or directory)
[pid  6550] stat("/usr/local/share/perl/5.22.1/DynaLoader.pm", 0x7ffdda87f1b0) 
= -1 ENOENT (No such file or directory)
[pid  6550] stat("/usr/lib/x86_64-linux-gnu/perl5/5.22/DynaLoader.pmc", 
0x7ffdda87f280) = -1 ENOENT (No such file or directory)
[pid  6550] stat("/usr/lib/x86_64-linux-gnu/perl5/5.22/DynaLoader.pm", 
0x7ffdda87f1b0) = -1 ENOENT (No such file or directory)
[pid  6550] stat("/usr/share/perl5/DynaLoader.pmc", 0x7ffdda87f280) = -1 ENOENT 
(No such file or directory)
[pid  6550] stat("/usr/share/perl5/DynaLoader.pm", 0x7ffdda87f1b0) = -1 ENOENT 
(No such file or directory)
[pid  6550] stat("/usr/lib/x86_64-linux-gnu/perl/5.22/DynaLoader.pmc", 
0x7ffdda87f280) = -1 ENOENT (No such file or directory)
[pid  6550] stat("/usr/lib/x86_64-linux-gnu/perl/5.22/DynaLoader.pm", 
{st_mode=S_IFREG|0644, st_size=10748, ...}) = 0
[pid  6550] open("/usr/lib/x86_64-linux-gnu/perl/5.22/DynaLoader.pm", O_RDONLY) 
= 5
[pid  6550] ioctl(5, TCGETS, 0x7ffdda87ef50) = -1 ENOTTY (Inappropriate ioctl 
for device)
[pid  6550] lseek(5, 0, SEEK_CUR)   = 0
[pid  6550] read(5, "# Generated from DynaLoader_pm.P"..., 8192) = 8192
[pid  6550] --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, 
si_addr=0x7f491064fa00} ---
[pid  6550] chdir("/etc/apache2")   = 0
[pid  6550] rt_sigaction(SIGSEGV, {SIG_DFL, [], SA_RESTORER|SA_INTERRUPT, 
0x7f4918dea3d0}, {SIG_DFL, [], SA_RESTORER|SA_RESETHAND, 0x7f4918dea3d0}, 8) = 0
[pid  6550] kill(6550, SIGSEGV) = 0
[pid  6550] rt_sigreturn({mask=[]}) = 139951873083648
[pid  6550] --- SIGSEGV {si_signo=SIGSEGV, si_code=SI_USER, si_pid=6550, 
si_uid=0} ---
[pid  6549] +++ exited with 0 +++
+++ killed by SIGSEGV (core dumped) +++

[[[ END PASTE SNIPPET ]]]



On 11/14/2016 at 11:54 PM, "Jie Gao"  wrote:
Add the "-f" flag to strace and see what errors you get.


Regards,

Jie

* William N. Braswell, Jr.  wrote:

> Date: Mon, 14 Nov 2016 23:27:53 -0600
> From: "William N. Braswell, Jr." 
> To: modperl@perl.apache.org
> Subject: mod_perl Silent Failure, Very Mysterious
>
> Hello everyone, I'm trying to enable a web app (Catalyst ShinyCMS) to
> run under mod_perl, it is definitely supposed to work but it fails
> without any errors, and I've been trying for several days to get it
> working.
> My system info:
> * Perl 5, version 22, subversion 1 (v5.22.1) built for
> x86_64-linux-gnu-thread-multi
> * libapache2-mod-perl2 v2.0.9-4ubuntu1
> * Apache/2.4.18 (Ubuntu)
> * $Apache::Test::VERSION = 1.39
> * $Catalyst::VERSION = 5.90112
> * $ShinyCMS::VERSION = 0.007
> I know the app already functions properly when running via the
> stand-

Re: mod_perl Silent Failure, Very Mysterious

[William N. Braswell, Jr.]

Hello Jie & Friends,
I got the core dump out of gdb and also some hopefully-helpful output.
Here is the output from gdb (not the core dump which is binary of
course):
http://hastebin.com/okaxacuriq.scala

Then again maybe we have a problem because I'm missing debugging
symbols inside /usr/sbin/apache2?

_Program received signal SIGSEGV, Segmentation fault.   
0x7fffeed67a00 in ?? ()_

Note the _??_ part in the output above...
Where do I go from here?
Thanks,~ Will

On 11/15/2016 at 12:14 AM, "William N. Braswell, Jr."  wrote:Hi Jie,
I have captured the output of `strace -f /usr/sbin/apache2 -e trace8
-k start`:
http://hastebin.com/unupocozop.pl
Looks like it is dying with a segfault, but I'm not sure what is
causing this???
Thanks so much for your help!!!  :-)
~ Will

[[[ BEGIN PASTE SNIPPET ]]]
[pid  6550] stat("blib/lib/DynaLoader.pmc", 0x7ffdda87f280) = -1
ENOENT (No such file or directory)[pid  6550]
stat("blib/lib/DynaLoader.pm", 0x7ffdda87f1b0) = -1 ENOENT (No such
file or directory)[pid  6550] stat("/etc/perl/DynaLoader.pmc",
0x7ffdda87f280) = -1 ENOENT (No such file or directory)[pid  6550]
stat("/etc/perl/DynaLoader.pm", 0x7ffdda87f1b0) = -1 ENOENT (No such
file or directory)[pid  6550]
stat("/usr/local/lib/x86_64-linux-gnu/perl/5.22.1/DynaLoader.pmc",
0x7ffdda87f280) = -1 ENOENT (No such file or directory)[pid  6550]
stat("/usr/local/lib/x86_64-linux-gnu/perl/5.22.1/DynaLoader.pm",
0x7ffdda87f1b0) = -1 ENOENT (No such file or directory)[pid  6550]
stat("/usr/local/share/perl/5.22.1/DynaLoader.pmc", 0x7ffdda87f280) =
-1 ENOENT (No such file or directory)[pid  6550]
stat("/usr/local/share/perl/5.22.1/DynaLoader.pm", 0x7ffdda87f1b0) =
-1 ENOENT (No such file or directory)[pid  6550]
stat("/usr/lib/x86_64-linux-gnu/perl5/5.22/DynaLoader.pmc",
0x7ffdda87f280) = -1 ENOENT (No such file or directory)[pid  6550]
stat("/usr/lib/x86_64-linux-gnu/perl5/5.22/DynaLoader.pm",
0x7ffdda87f1b0) = -1 ENOENT (No such file or directory)[pid  6550]
stat("/usr/share/perl5/DynaLoader.pmc", 0x7ffdda87f280) = -1 ENOENT
(No such file or directory)[pid  6550]
stat("/usr/share/perl5/DynaLoader.pm", 0x7ffdda87f1b0) = -1 ENOENT (No
such file or directory)[pid  6550]
stat("/usr/lib/x86_64-linux-gnu/perl/5.22/DynaLoader.pmc",
0x7ffdda87f280) = -1 ENOENT (No such file or directory)[pid  6550]
stat("/usr/lib/x86_64-linux-gnu/perl/5.22/DynaLoader.pm",
{st_mode=S_IFREG|0644, st_size=10748, ...}) = 0[pid  6550]
open("/usr/lib/x86_64-linux-gnu/perl/5.22/DynaLoader.pm", O_RDONLY) =
5[pid  6550] ioctl(5, TCGETS, 0x7ffdda87ef50) = -1 ENOTTY
(Inappropriate ioctl for device)[pid  6550] lseek(5, 0, SEEK_CUR) 
 = 0[pid  6550] read(5, "# Generated from DynaLoader_pm.P"..., 8192) =
8192[pid  6550] --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR,
si_addr=0x7f491064fa00} ---[pid  6550] chdir("/etc/apache2")   =
0[pid  6550] rt_sigaction(SIGSEGV, {SIG_DFL, [],
SA_RESTORER|SA_INTERRUPT, 0x7f4918dea3d0}, {SIG_DFL, [],
SA_RESTORER|SA_RESETHAND, 0x7f4918dea3d0}, 8) = 0[pid  6550]
kill(6550, SIGSEGV) = 0[pid  6550] rt_sigreturn({mask=[]})
= 139951873083648[pid  6550] --- SIGSEGV {si_signo=SIGSEGV,
si_code=SI_USER, si_pid=6550, si_uid=0} ---[pid  6549] +++ exited with
0 ++ killed by SIGSEGV (core dumped) +++
[[[ END PASTE SNIPPET ]]]
On 11/14/2016 at 11:54 PM, "Jie Gao"  wrote:Add the "-f" flag to
strace and see what errors you get.
Regards,

Jie 

* William N. Braswell, Jr.  wrote:

> Date: Mon, 14 Nov 2016 23:27:53 -0600
> From: "William N. Braswell, Jr." 
> To: modperl@perl.apache.org
> Subject: mod_perl Silent Failure, Very Mysterious
> 
> Hello everyone, I'm trying to enable a web app (Catalyst ShinyCMS)
to
> run under mod_perl, it is definitely supposed to work but it fails
> without any errors, and I've been trying for several days to get it
> working.
> My system info:
> * Perl 5, version 22, subversion 1 (v5.22.1) built for
> x86_64-linux-gnu-thread-multi
> * libapache2-mod-perl2 v2.0.9-4ubuntu1
> * Apache/2.4.18 (Ubuntu)
> * $Apache::Test::VERSION = 1.39
> * $Catalyst::VERSION = 5.90112
> * $ShinyCMS::VERSION = 0.007
> I know the app already functions properly when running via the
> stand-alone test server script (PSGI) or fastcgi, and I am able to
run
> a trivial Catalyst test application successfully under mod_perl, so
> this issue seems to have something to do with the interaction
between
> the ShinyCMS app and mod_perl.
> I have added print debug statements in my app, so when I call my app
> from within the Apache site conf file then I can see the debug
> statements prove that it is successfully going all the way through
my
> app, and it even returns control to the embedded  code w/in the
Apache
> site conf file, but it still just silently fails anyway with the
> following non-descriptive error:
> "The apache2 instance did not start within 20 seconds. Please read
the
> log files to discover problems"
> Unfortunately the log files do not provide any additional
information
> whatsoever!
> Here are my Apache c

Re: mod_perl Silent Failure, Very Mysterious

[William N. Braswell, Jr.]

Hi Jie,
I have captured the output of `strace -f /usr/sbin/apache2 -e trace8
-k start`:
http://hastebin.com/unupocozop.pl
Looks like it is dying with a segfault, but I'm not sure what is
causing this???
Thanks so much for your help!!!  :-)
~ Will

[[[ BEGIN PASTE SNIPPET ]]]
[pid  6550] stat("blib/lib/DynaLoader.pmc", 0x7ffdda87f280) = -1
ENOENT (No such file or directory)[pid  6550]
stat("blib/lib/DynaLoader.pm", 0x7ffdda87f1b0) = -1 ENOENT (No such
file or directory)[pid  6550] stat("/etc/perl/DynaLoader.pmc",
0x7ffdda87f280) = -1 ENOENT (No such file or directory)[pid  6550]
stat("/etc/perl/DynaLoader.pm", 0x7ffdda87f1b0) = -1 ENOENT (No such
file or directory)[pid  6550]
stat("/usr/local/lib/x86_64-linux-gnu/perl/5.22.1/DynaLoader.pmc",
0x7ffdda87f280) = -1 ENOENT (No such file or directory)[pid  6550]
stat("/usr/local/lib/x86_64-linux-gnu/perl/5.22.1/DynaLoader.pm",
0x7ffdda87f1b0) = -1 ENOENT (No such file or directory)[pid  6550]
stat("/usr/local/share/perl/5.22.1/DynaLoader.pmc", 0x7ffdda87f280) =
-1 ENOENT (No such file or directory)[pid  6550]
stat("/usr/local/share/perl/5.22.1/DynaLoader.pm", 0x7ffdda87f1b0) =
-1 ENOENT (No such file or directory)[pid  6550]
stat("/usr/lib/x86_64-linux-gnu/perl5/5.22/DynaLoader.pmc",
0x7ffdda87f280) = -1 ENOENT (No such file or directory)[pid  6550]
stat("/usr/lib/x86_64-linux-gnu/perl5/5.22/DynaLoader.pm",
0x7ffdda87f1b0) = -1 ENOENT (No such file or directory)[pid  6550]
stat("/usr/share/perl5/DynaLoader.pmc", 0x7ffdda87f280) = -1 ENOENT
(No such file or directory)[pid  6550]
stat("/usr/share/perl5/DynaLoader.pm", 0x7ffdda87f1b0) = -1 ENOENT (No
such file or directory)[pid  6550]
stat("/usr/lib/x86_64-linux-gnu/perl/5.22/DynaLoader.pmc",
0x7ffdda87f280) = -1 ENOENT (No such file or directory)[pid  6550]
stat("/usr/lib/x86_64-linux-gnu/perl/5.22/DynaLoader.pm",
{st_mode=S_IFREG|0644, st_size=10748, ...}) = 0[pid  6550]
open("/usr/lib/x86_64-linux-gnu/perl/5.22/DynaLoader.pm", O_RDONLY) =
5[pid  6550] ioctl(5, TCGETS, 0x7ffdda87ef50) = -1 ENOTTY
(Inappropriate ioctl for device)[pid  6550] lseek(5, 0, SEEK_CUR) 
 = 0[pid  6550] read(5, "# Generated from DynaLoader_pm.P"..., 8192) =
8192[pid  6550] --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR,
si_addr=0x7f491064fa00} ---[pid  6550] chdir("/etc/apache2")   =
0[pid  6550] rt_sigaction(SIGSEGV, {SIG_DFL, [],
SA_RESTORER|SA_INTERRUPT, 0x7f4918dea3d0}, {SIG_DFL, [],
SA_RESTORER|SA_RESETHAND, 0x7f4918dea3d0}, 8) = 0[pid  6550]
kill(6550, SIGSEGV) = 0[pid  6550] rt_sigreturn({mask=[]})
= 139951873083648[pid  6550] --- SIGSEGV {si_signo=SIGSEGV,
si_code=SI_USER, si_pid=6550, si_uid=0} ---[pid  6549] +++ exited with
0 ++ killed by SIGSEGV (core dumped) +++
[[[ END PASTE SNIPPET ]]]
On 11/14/2016 at 11:54 PM, "Jie Gao"  wrote:Add the "-f" flag to
strace and see what errors you get.
Regards,

Jie 

* William N. Braswell, Jr.  wrote:

> Date: Mon, 14 Nov 2016 23:27:53 -0600
> From: "William N. Braswell, Jr." 
> To: modperl@perl.apache.org
> Subject: mod_perl Silent Failure, Very Mysterious
> 
> Hello everyone, I'm trying to enable a web app (Catalyst ShinyCMS)
to
> run under mod_perl, it is definitely supposed to work but it fails
> without any errors, and I've been trying for several days to get it
> working.
> My system info:
> * Perl 5, version 22, subversion 1 (v5.22.1) built for
> x86_64-linux-gnu-thread-multi
> * libapache2-mod-perl2 v2.0.9-4ubuntu1
> * Apache/2.4.18 (Ubuntu)
> * $Apache::Test::VERSION = 1.39
> * $Catalyst::VERSION = 5.90112
> * $ShinyCMS::VERSION = 0.007
> I know the app already functions properly when running via the
> stand-alone test server script (PSGI) or fastcgi, and I am able to
run
> a trivial Catalyst test application successfully under mod_perl, so
> this issue seems to have something to do with the interaction
between
> the ShinyCMS app and mod_perl.
> I have added print debug statements in my app, so when I call my app
> from within the Apache site conf file then I can see the debug
> statements prove that it is successfully going all the way through
my
> app, and it even returns control to the embedded  code w/in the
Apache
> site conf file, but it still just silently fails anyway with the
> following non-descriptive error:
> "The apache2 instance did not start within 20 seconds. Please read
the
> log files to discover problems"
> Unfortunately the log files do not provide any additional
information
> whatsoever!
> Here are my Apache config files and the output of trying to start
> Apache manually, you can see my ">" statements which prove that my
> ShinyCMS app code is definitely executing all the way through and
> returning control to Apache:
> http://hastebin.com/rulixitole.php
> http://hastebin.com/wevicagano.rb
> This is a really mysterious issue, when I run `apache2ctl -e debug
-k
> start` as seen in the link above, it goes through the motions as if
it
> is starting correctly, and it does not give any error messages, but
> when apache2ctl is done there s

Re: mod_perl Silent Failure, Very Mysterious

[Jie Gao]

Add the "-f" flag to strace and see what errors you get.


Regards,

Jie 

* William N. Braswell, Jr.  wrote:

> Date: Mon, 14 Nov 2016 23:27:53 -0600
> From: "William N. Braswell, Jr." 
> To: modperl@perl.apache.org
> Subject: mod_perl Silent Failure, Very Mysterious
> 
> Hello everyone, I'm trying to enable a web app (Catalyst ShinyCMS) to
> run under mod_perl, it is definitely supposed to work but it fails
> without any errors, and I've been trying for several days to get it
> working.
> My system info:
> * Perl 5, version 22, subversion 1 (v5.22.1) built for
> x86_64-linux-gnu-thread-multi
> * libapache2-mod-perl2 v2.0.9-4ubuntu1
> * Apache/2.4.18 (Ubuntu)
> * $Apache::Test::VERSION = 1.39
> * $Catalyst::VERSION = 5.90112
> * $ShinyCMS::VERSION = 0.007
> I know the app already functions properly when running via the
> stand-alone test server script (PSGI) or fastcgi, and I am able to run
> a trivial Catalyst test application successfully under mod_perl, so
> this issue seems to have something to do with the interaction between
> the ShinyCMS app and mod_perl.
> I have added print debug statements in my app, so when I call my app
> from within the Apache site conf file then I can see the debug
> statements prove that it is successfully going all the way through my
> app, and it even returns control to the embedded  code w/in the Apache
> site conf file, but it still just silently fails anyway with the
> following non-descriptive error:
> "The apache2 instance did not start within 20 seconds. Please read the
> log files to discover problems"
> Unfortunately the log files do not provide any additional information
> whatsoever!
> Here are my Apache config files and the output of trying to start
> Apache manually, you can see my ">" statements which prove that my
> ShinyCMS app code is definitely executing all the way through and
> returning control to Apache:
> http://hastebin.com/rulixitole.php
> http://hastebin.com/wevicagano.rb
> This is a really mysterious issue, when I run `apache2ctl -e debug -k
> start` as seen in the link above, it goes through the motions as if it
> is starting correctly, and it does not give any error messages, but
> when apache2ctl is done there simply are not any apache processes
> running...
> I only found 1 person on google with a possibly-similar issue, but he
> told me that he never found a solution:
> https://github.com/timbunce/devel-nytprof/issues/89
> I also found 1 person on the mod_perl mailing list archives with
> another possibly-similar issue, but I have no way to follow up, and
> I'm not sure of the best way to totally rebuild everything from
> source:
> https://mail-archives.apache.org/mod_mbox/perl-modperl/200207.mbox/%3c4a19f19a1bb4d51183220020ed06971401288...@exch2.iso-ne.com%3E
> I have asked for help on IRC #httpd, user Unbeliever suggested I
> ascertain my real /usr/sbin/apache2 command line and run it through
> strace, then post to this mailing list.
> I used -x in apache2ctl which showed me I was simply sourcing
> /tmp/apache2/envvars and then running `/usr/sbin/apache2 -e trace8 -k
> start` which are the exact same args as accepted by the apache2ctl
> script.
> I have now run `strace /usr/sbin/apache2 -e trace8 -k start` which
> generates 2.5MB of text output, I have pasted the last few pages of it
> on hastebin, I can post the whole thing for download if needed:
> http://hastebin.com/idemogexiq.erl
> I am not sure how to interpret the results of the strace command
> output and debug this issue, help please?
> Any and all assistance is greatly appreciated!  :-)
> Thanks,~ Will

Re: mod_perl 2.0.9 make test dumped core

[tomcat]

On 10.05.2016 22:20, Niko Tyni wrote:

On Tue, May 10, 2016 at 07:45:45PM +, Xinhuan Zheng wrote:


Today I used mod_perl 2.0.9, apache httpd 2.4.20 and perl 5.10.1


isn't this also a somewhat low version of perl ? the current version is at least 5.22, and 
5.10 must be at least 3-4 years old.


 to try compiling mod_perl DSO object on centos 6 (x86_64) machine. It passed configure 
and make but failed ‘make test’.



[  error] oh dangit, server dumped core
[  error] for stacktrace, run: gdb /usr/local/apache-2.4.20-catalyst/bin/httpd 
-core /tmp/mod_perl-2.0.9/t/core.2184


There's a known issue with t/protocol/pseudo_http.t crashing Apache
2.4.20, see

http://www.mail-archive.com/dev%40perl.apache.org/msg13696.html

Re: mod_perl 2.0.9 make test dumped core

[Niko Tyni]

On Tue, May 10, 2016 at 07:45:45PM +, Xinhuan Zheng wrote:
 
> Today I used mod_perl 2.0.9, apache httpd 2.4.20 and perl 5.10.1 to try 
> compiling mod_perl DSO object on centos 6 (x86_64) machine. It passed 
> configure and make but failed ‘make test’.

> [  error] oh dangit, server dumped core
> [  error] for stacktrace, run: gdb 
> /usr/local/apache-2.4.20-catalyst/bin/httpd -core 
> /tmp/mod_perl-2.0.9/t/core.2184

There's a known issue with t/protocol/pseudo_http.t crashing Apache
2.4.20, see

http://www.mail-archive.com/dev%40perl.apache.org/msg13696.html

-- 
Niko Tyni   nt...@debian.org

Re: mod_perl startup script and logging

[tomcat]

Sorry, never mind, found it :

my $server = Apache2::ServerUtil->server();
my $apache_version = Apache2::ServerUtil::get_server_version();
$server->log_error("mp2-startup: server version is " . $apache_version);

On 10.04.2016 16:48, André Warnier (tomcat) wrote:

Hi.
Linux Debian
Apache httpd 2.4
mod_perl 2.0.9

...
PerlPostConfigRequire "/etc/apache2/modperl2_startup.pl"
...

modperl2_startup.pl contains the usual "use" directives, including
   use Apache2::ServerRec ();
   use Apache2::ServerUtil ();
   use Apache2::Log ();

If in this script, I would like to log something to the Apache server log 
(error_log), how
do I do that ?
(I mean e.g., how can I get the server object, from inside modperl2_startup.pl 
?)

[Rusonyx #1409057]: Re: mod_perl and apache 2.4

[Rusonyx Support Team]

Michael Schout,

Вы написали в компанию Русоникс и это письмо является автоматическим
подтверждением того, что Ваша заявка поступила в очередь на обработку.
Мы ответим на Ваш запрос по возможности максимально быстро.

ID Заявки: 1409057
Тема: Re: mod_perl and apache 2.4
Отдел: Support
Тип: Issue
Статус: Open
Приоритет: Medium
С уважением
ООО Русоникс
www.rusonyx.ru 

Rusonyx


--
Портал технической поддержки: https://support.rusonyx.ru/index.php?

Re: mod_perl and apache 2.4

[Michael Schout]

On 5/8/15 7:55 PM, GLG wrote:
> It doesn't matter how I install mod_perl (dynamic or static. Also tried via
> Webmin), the end result is always the same. This on FreeBSD 10.1
...
> httpd: Syntax error on line 107 of /usr/local/etc/apache22/httpd.conf:
> Cannot load /usr/local/libexec/apache22/mod_perl.so into server:
> /usr/local/libexec/apache22/mod_perl.so: Undefined symbol
> "modperl_io_perlio_restore_stdout"
> -

I know this is old, but I'm going to reply because I ran into this a
while back (and solved it).  Hopefully I can help others.

This problem has to do with the fact that FreeBSD uses clang to compile
mod_perl, and clang handles C99 inline functions differently from gcc's
default mode (which is C89 for GCC < 5.0).  You'll run into this exact
same problem everywhere clang is used (e.g.: OS X).

The short answer is you have two choices:

1) compile with gcc
or
2) patch src/modules/perl/modperl_common_util.h and make sure APR_INLINE
is not defined before compiling.

See the ports Makefile in www/mod_perl2 under the post-patch rule for
how the ports tree handles this (unset APR_INLINE)

I realize this may be too late to help you, but hopefully this will help
someone else down the line.

See: http://clang.llvm.org/compatibility.html#inline

Regards,
Michael Schout

Re: mod_perl cannot find startup.pl

[Kevin A. McGrail]

On 7/8/2015 8:01 PM, Jim Garrison wrote:

D'OH!!! I was sure I had turned off selinux, but had not.

That was a very good call.

No worries, we've all been there.

regards,
KAM

Re: mod_perl cannot find startup.pl

[Jim Garrison]

On 7/8/2015 4:44 PM, Kevin A. McGrail wrote:
> Anything like selinux? 
> 
> If you put the startup.pl in the same dir as the config file and chown
> to the same user apache is using?
> 
> Regards,
> KAM
> 
> On 7/8/2015 7:38 PM, Jim Garrison wrote:
>> Running Centos 6.6 with Apache 2.2.15 and mod_perl 2.0.4
>>
>> I'm trying to add a startup script (startup.pl) but cannot seem to get
>> mod_perl to find it.  I've reduced the config down to the bare minimum
>> that still reproduces the issue for me.
>>
>> Perl apache configuration:
[snip]


D'OH!!! I was sure I had turned off selinux, but had not.

That was a very good call.

Thank you!

-- 
Jim Garrison (j...@acm.org)
PGP Keys at http://www.jhmg.net RSA 0x04B73B7F DH 0x70738D88

RE: mod_perl and apache 2.4

[GLG]

SOLVED. I messed around with Poudriere, but it kept insisting that I
re-instal Apache24 over Apache22 (completely ignoring make.conf or command
line parameters), which I'd previously learned doesn't work with mod_perl2.
I even tried to lock Apache22, but it just would not create a package with
that version. What a dilemma.

Then I was lucky enough to discover a mod_perl2 development snapshot package
that also insisted on re-installing Apache24, but it was worth a try at this
point, and it worked perfectly (ap24-mod_perl2-2.0.8_4,3). Thanks everyone.

-Original Message-
From: GLG [mailto:i...@3dnetproductions.com] 
Sent: Sunday, May 10, 2015 2:58 PM
To: 'mod_perl list'
Subject: RE: mod_perl and apache 2.4

No disrespect intended folks, For a while I was just wondering if I was at
the right place, not wanting to annoy people out-of-place in a public list.
But I did receive assistance and something to go on. Tomorrow I will
remove/deinstall everything mod_perl related from the system, reinstall as
prescribed and report back here. Hopefully, my experience will help others
in the future. Thank you, 

-Original Message-
From: Vincent Veyron [mailto:vv.li...@wanadoo.fr] 
Sent: Sunday, May 10, 2015 8:28 AM
To: Jie Gao
Cc: GLG; 'mod_perl list'
Subject: Re: mod_perl and apache 2.4

On Sun, 10 May 2015 11:58:56 +1000
Jie Gao  wrote:
> 
> You've now got help from Randal! So you know this is really mod_perl list.
:-)
> 

Well put!


-- 
Salutations, Vincent Veyron 

https://legalcase.libremen.com/ 
Legal case, contract and insurance claim management software

RE: mod_perl and apache 2.4

[GLG]

No disrespect intended folks, For a while I was just wondering if I was at
the right place, not wanting to annoy people out-of-place in a public list.
But I did receive assistance and something to go on. Tomorrow I will
remove/deinstall everything mod_perl related from the system, reinstall as
prescribed and report back here. Hopefully, my experience will help others
in the future. Thank you, 

-Original Message-
From: Vincent Veyron [mailto:vv.li...@wanadoo.fr] 
Sent: Sunday, May 10, 2015 8:28 AM
To: Jie Gao
Cc: GLG; 'mod_perl list'
Subject: Re: mod_perl and apache 2.4

On Sun, 10 May 2015 11:58:56 +1000
Jie Gao  wrote:
> 
> You've now got help from Randal! So you know this is really mod_perl list.
:-)
> 

Well put!


-- 
Salutations, Vincent Veyron 

https://legalcase.libremen.com/ 
Legal case, contract and insurance claim management software

Re: mod_perl and apache 2.4

[Vincent Veyron]

On Sun, 10 May 2015 11:58:56 +1000
Jie Gao  wrote:
> 
> You've now got help from Randal! So you know this is really mod_perl list. :-)
> 

Well put!


-- 
Salutations, Vincent Veyron 

https://legalcase.libremen.com/ 
Legal case, contract and insurance claim management software

Re: mod_perl and apache 2.4

[Jie Gao]

Hi GLG

You've now got help from Randal! So you know this is really mod_perl list. :-)


Regards,

Jie 

* Randal L. Schwartz  wrote:

> Date: Sat, 9 May 2015 07:56:06 -0700
> From: "Randal L. Schwartz" 
> To: GLG 
> CC: 'Jie Gao' , 'mod_perl list'
>  
> Subject: Re: mod_perl and apache 2.4
> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (berkeley-unix)
> 
> >>>>> "GLG" == GLG   writes:
> 
> GLG> Thanks for the suggestions. Not running FreeBSD may lead to deeper issues
> GLG> for us because of the type of work that we do. Downgrading could be an
> GLG> option but there is already so much done, and services running like 
> email,
> GLG> etc. I'd rather try to find the problem as is.
> 
> I came in late to this thread, but if you're running FreeBSD, do *not*
> mix ports with packages.  As in, don't hand-compile some things, but
> "pkg install" other things.  If you want the convenience of locally
> customized ports as packages, use poudriere and create your own package
> repo with your own custom settings.
> 
> -- 
> Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
>  http://www.stonehenge.com/merlyn/>
> Perl/Unix consulting, Technical writing, Comedy, etc. etc.
> Still trying to think of something clever for the fourth line of this .sig

Re: mod_perl and apache 2.4

[Randal L. Schwartz]

> "GLG" == GLG   writes:

GLG> Thanks for the suggestions. Not running FreeBSD may lead to deeper issues
GLG> for us because of the type of work that we do. Downgrading could be an
GLG> option but there is already so much done, and services running like email,
GLG> etc. I'd rather try to find the problem as is.

I came in late to this thread, but if you're running FreeBSD, do *not*
mix ports with packages.  As in, don't hand-compile some things, but
"pkg install" other things.  If you want the convenience of locally
customized ports as packages, use poudriere and create your own package
repo with your own custom settings.

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
 http://www.stonehenge.com/merlyn/>
Perl/Unix consulting, Technical writing, Comedy, etc. etc.
Still trying to think of something clever for the fourth line of this .sig

RE: mod_perl and apache 2.4

[Jie Gao]

If it's a permissions issue, you probably already know what to do. -Jie

From: GLG [i...@3dnetproductions.com]
Sent: Saturday, May 09, 2015 4:33 PM
To: Jie Gao; 'mod_perl list'
Subject: RE: mod_perl and apache 2.4

Thanks for the suggestions. Not running FreeBSD may lead to deeper issues
for us because of the type of work that we do. Downgrading could be an
option but there is already so much done, and services running like email,
etc. I'd rather try to find the problem as is.

I ran ktrace twice. Once with Apache loading mod_perl, and once without
loading it. The kdump output files are identical for all practical purposes.
They also have exactly the same size.

Apache runs without mod_perl, but I also find this in both files:

69375 ktrace   CALL  execve(0x7fffe550,0x7fffeae0,0x7fffeb00)
69375 ktrace   NAMI  "/usr/bin/apachectl"
69375 ktrace   RET   execve -1 errno 13 Permission denied






-Original Message-
From: Jie Gao [mailto:j@sydney.edu.au]
Sent: Saturday, May 09, 2015 12:31 AM
To: i...@3dnetproductions.com; 'mod_perl list'
Subject: RE: mod_perl and apache 2.4

I can see the full name of functions in mod_perl.so with a "wide format"
now, so they do exist. But they are in the relocation section.

Run "strace -f apachectl restart" to see where it erred by what function /
calling what file. There might be some restriction to what lib files you are
allowed to load.

I'd change OS to save time.

-Jie


From: Jie Gao [j@sydney.edu.au]
Sent: Saturday, May 09, 2015 11:59 AM
To: i...@3dnetproductions.com; 'mod_perl list'
Subject: RE: mod_perl and apache 2.4

mod_perl.so indeed does not have "modperl_io_perlio_restore_stdout", nor
"modperl_io_perlio_restore_stdin";
it does have "modperl_io_perlio_restore", which does not seem to be defined
anywhere in the source. Not sure why.

-JIie

From: GLG [i...@3dnetproductions.com]
Sent: Saturday, May 09, 2015 10:55 AM
To: 'mod_perl list'
Subject: RE: mod_perl and apache 2.4

It doesn't matter how I install mod_perl (dynamic or static. Also tried via
Webmin), the end result is always the same. This on FreeBSD 10.1

As soon as I add this line to httpd.conf

LoadModule perl_module libexec/apache22/mod_perl.so

and attempt to restart Apache, I get this...


apachectl restart

Now reading network conf in..  /etc/rc.conf
Now reading network conf in..  /etc/rc.conf
Performing sanity check on apache22 configuration:
httpd: Syntax error on line 107 of /usr/local/etc/apache22/httpd.conf:
Cannot load /usr/local/libexec/apache22/mod_perl.so into server:
/usr/local/libexec/apache22/mod_perl.so: Undefined symbol
"modperl_io_perlio_restore_stdout"
-

I have verified that mod_perl.so is in place. What on Earth is

'Undefined symbol "modperl_io_perlio_restore_stdout"'???


Is this really a mod_perl list?

Thank you,





-Original Message-
From: GLG [mailto:i...@3dnetproductions.com]
Sent: Friday, May 01, 2015 7:12 PM
To: 'mod_perl list'
Subject: RE: mod_perl and apache 2.4

Thanks André. Your info was useful.  I can't say that I solved this yet, but
I did find something strange.

But first, I no longer think there's an issue with libtool. It looks like
there's a fix running.

Secondly, I had to 'pkg install p5-BSD-Resource' dependency manually,
because the automatic installation by mod_perl2 didn't work.

And third, Can't really do 'make test' either because it has to run as a
priviledged user, and then Apache wants a non-priviledged user for the test
suite. Can't have both. So no dice.

But see below for where the real problem seems to be:

Short version:

Notice how gmake is installing mod_perl in ../ ../mach/5.18/ <--- correct
  but later tries to read from ../ ../5.18/mach/ <--- incorrect

Something is backward??? What is the right way to resolve this? I have been
at it way too long. Thanks,

--
Longer version:

[root@x /usr/ports/www/mod_perl2]# make install clean
===>  Staging for ap22-mod_perl2-2.0.8_2,3
===>   ap22-mod_perl2-2.0.8_2,3 depends on package: p5-BSD-Resource>=0 -
found
===>   ap22-mod_perl2-2.0.8_2,3 depends on file: /usr/local/sbin/apxs -
found
===>   ap22-mod_perl2-2.0.8_2,3 depends on file: /usr/local/bin/perl5.18.4 -
found
===>   Generating temporary packing list
gmake[1]: Entering directory '/usr/ports/www/mod_perl2/work/mod_perl-2.0.8'

... more stuff here

Installing
/usr/ports/www/mod_perl2/work/stage/usr/local/lib/perl5/site_perl/mach/5.18/

... more of the same here

 find:
/usr/ports/www/mod_perl2/work/stage/usr/local

RE: mod_perl and apache 2.4

[GLG]

Thanks for the suggestions. Not running FreeBSD may lead to deeper issues
for us because of the type of work that we do. Downgrading could be an
option but there is already so much done, and services running like email,
etc. I'd rather try to find the problem as is.

I ran ktrace twice. Once with Apache loading mod_perl, and once without
loading it. The kdump output files are identical for all practical purposes.
They also have exactly the same size.
 
Apache runs without mod_perl, but I also find this in both files: 

69375 ktrace   CALL  execve(0x7fffe550,0x7fffeae0,0x7fffeb00)
69375 ktrace   NAMI  "/usr/bin/apachectl"
69375 ktrace   RET   execve -1 errno 13 Permission denied






-Original Message-
From: Jie Gao [mailto:j@sydney.edu.au] 
Sent: Saturday, May 09, 2015 12:31 AM
To: i...@3dnetproductions.com; 'mod_perl list'
Subject: RE: mod_perl and apache 2.4

I can see the full name of functions in mod_perl.so with a "wide format"
now, so they do exist. But they are in the relocation section.

Run "strace -f apachectl restart" to see where it erred by what function /
calling what file. There might be some restriction to what lib files you are
allowed to load.

I'd change OS to save time.

-Jie


From: Jie Gao [j@sydney.edu.au]
Sent: Saturday, May 09, 2015 11:59 AM
To: i...@3dnetproductions.com; 'mod_perl list'
Subject: RE: mod_perl and apache 2.4

mod_perl.so indeed does not have "modperl_io_perlio_restore_stdout", nor
"modperl_io_perlio_restore_stdin";
it does have "modperl_io_perlio_restore", which does not seem to be defined
anywhere in the source. Not sure why.

-JIie

From: GLG [i...@3dnetproductions.com]
Sent: Saturday, May 09, 2015 10:55 AM
To: 'mod_perl list'
Subject: RE: mod_perl and apache 2.4

It doesn't matter how I install mod_perl (dynamic or static. Also tried via
Webmin), the end result is always the same. This on FreeBSD 10.1

As soon as I add this line to httpd.conf

LoadModule perl_module libexec/apache22/mod_perl.so

and attempt to restart Apache, I get this...


apachectl restart

Now reading network conf in..  /etc/rc.conf
Now reading network conf in..  /etc/rc.conf
Performing sanity check on apache22 configuration:
httpd: Syntax error on line 107 of /usr/local/etc/apache22/httpd.conf:
Cannot load /usr/local/libexec/apache22/mod_perl.so into server:
/usr/local/libexec/apache22/mod_perl.so: Undefined symbol
"modperl_io_perlio_restore_stdout"
-

I have verified that mod_perl.so is in place. What on Earth is

'Undefined symbol "modperl_io_perlio_restore_stdout"'???


Is this really a mod_perl list?

Thank you,





-----Original Message-
From: GLG [mailto:i...@3dnetproductions.com]
Sent: Friday, May 01, 2015 7:12 PM
To: 'mod_perl list'
Subject: RE: mod_perl and apache 2.4

Thanks André. Your info was useful.  I can't say that I solved this yet, but
I did find something strange.

But first, I no longer think there's an issue with libtool. It looks like
there's a fix running.

Secondly, I had to 'pkg install p5-BSD-Resource' dependency manually,
because the automatic installation by mod_perl2 didn't work.

And third, Can't really do 'make test' either because it has to run as a
priviledged user, and then Apache wants a non-priviledged user for the test
suite. Can't have both. So no dice.

But see below for where the real problem seems to be:

Short version:

Notice how gmake is installing mod_perl in ../ ../mach/5.18/ <--- correct
  but later tries to read from ../ ../5.18/mach/ <--- incorrect

Something is backward??? What is the right way to resolve this? I have been
at it way too long. Thanks,

--
Longer version:

[root@x /usr/ports/www/mod_perl2]# make install clean
===>  Staging for ap22-mod_perl2-2.0.8_2,3
===>   ap22-mod_perl2-2.0.8_2,3 depends on package: p5-BSD-Resource>=0 -
found
===>   ap22-mod_perl2-2.0.8_2,3 depends on file: /usr/local/sbin/apxs -
found
===>   ap22-mod_perl2-2.0.8_2,3 depends on file: /usr/local/bin/perl5.18.4 -
found
===>   Generating temporary packing list
gmake[1]: Entering directory '/usr/ports/www/mod_perl2/work/mod_perl-2.0.8'

... more stuff here

Installing
/usr/ports/www/mod_perl2/work/stage/usr/local/lib/perl5/site_perl/mach/5.18/

... more of the same here

 find:
/usr/ports/www/mod_perl2/work/stage/usr/local/lib/perl5/site_perl/5.18/mach/
auto: No such file or directory
> Compressing man pages (compress-man)
===>  Installing for ap22-mod_perl2-2.0.8_2,3
===>  Checking if ap22-mod_perl2 already installed
===>   Registering installation for ap22-mod_perl2-2

RE: mod_perl and apache 2.4

[Jie Gao]

I can see the full name of functions in mod_perl.so with a "wide format" now, 
so they do exist. But they are in the relocation section.

Run "strace -f apachectl restart" to see where it erred by what function / 
calling what file. There might be some restriction to what lib files you are 
allowed to load.

I'd change OS to save time.

-Jie


From: Jie Gao [j@sydney.edu.au]
Sent: Saturday, May 09, 2015 11:59 AM
To: i...@3dnetproductions.com; 'mod_perl list'
Subject: RE: mod_perl and apache 2.4

mod_perl.so indeed does not have "modperl_io_perlio_restore_stdout", nor 
"modperl_io_perlio_restore_stdin";
it does have "modperl_io_perlio_restore", which does not seem to be defined 
anywhere in the source. Not sure why.

-JIie

From: GLG [i...@3dnetproductions.com]
Sent: Saturday, May 09, 2015 10:55 AM
To: 'mod_perl list'
Subject: RE: mod_perl and apache 2.4

It doesn't matter how I install mod_perl (dynamic or static. Also tried via
Webmin), the end result is always the same. This on FreeBSD 10.1

As soon as I add this line to httpd.conf

LoadModule perl_module libexec/apache22/mod_perl.so

and attempt to restart Apache, I get this...


apachectl restart

Now reading network conf in..  /etc/rc.conf
Now reading network conf in..  /etc/rc.conf
Performing sanity check on apache22 configuration:
httpd: Syntax error on line 107 of /usr/local/etc/apache22/httpd.conf:
Cannot load /usr/local/libexec/apache22/mod_perl.so into server:
/usr/local/libexec/apache22/mod_perl.so: Undefined symbol
"modperl_io_perlio_restore_stdout"
-

I have verified that mod_perl.so is in place. What on Earth is

'Undefined symbol "modperl_io_perlio_restore_stdout"'???


Is this really a mod_perl list?

Thank you,





-Original Message-
From: GLG [mailto:i...@3dnetproductions.com]
Sent: Friday, May 01, 2015 7:12 PM
To: 'mod_perl list'
Subject: RE: mod_perl and apache 2.4

Thanks André. Your info was useful.  I can't say that I solved this yet, but
I did find something strange.

But first, I no longer think there's an issue with libtool. It looks like
there's a fix running.

Secondly, I had to 'pkg install p5-BSD-Resource' dependency manually,
because the automatic installation by mod_perl2 didn't work.

And third, Can't really do 'make test' either because it has to run as a
priviledged user, and then Apache wants a non-priviledged user for the test
suite. Can't have both. So no dice.

But see below for where the real problem seems to be:

Short version:

Notice how gmake is installing mod_perl in ../ ../mach/5.18/ <--- correct
  but later tries to read from ../ ../5.18/mach/ <--- incorrect

Something is backward??? What is the right way to resolve this? I have been
at it way too long. Thanks,

--
Longer version:

[root@x /usr/ports/www/mod_perl2]# make install clean
===>  Staging for ap22-mod_perl2-2.0.8_2,3
===>   ap22-mod_perl2-2.0.8_2,3 depends on package: p5-BSD-Resource>=0 -
found
===>   ap22-mod_perl2-2.0.8_2,3 depends on file: /usr/local/sbin/apxs -
found
===>   ap22-mod_perl2-2.0.8_2,3 depends on file: /usr/local/bin/perl5.18.4 -
found
===>   Generating temporary packing list
gmake[1]: Entering directory '/usr/ports/www/mod_perl2/work/mod_perl-2.0.8'

... more stuff here

Installing
/usr/ports/www/mod_perl2/work/stage/usr/local/lib/perl5/site_perl/mach/5.18/

... more of the same here

 find:
/usr/ports/www/mod_perl2/work/stage/usr/local/lib/perl5/site_perl/5.18/mach/
auto: No such file or directory
> Compressing man pages (compress-man)
===>  Installing for ap22-mod_perl2-2.0.8_2,3
===>  Checking if ap22-mod_perl2 already installed
===>   Registering installation for ap22-mod_perl2-2.0.8_2,3
pkg-static: Unable to access file
/usr/ports/www/mod_perl2/work/stage/usr/local/===>
ap24-mod_perl2-2.0.8_2,3 depends on package: p5-BSD-Resource>=0 - not found:
No such file or directory
pkg-static: Unable to access file
/usr/ports/www/mod_perl2/work/stage/usr/local/===>Verifying install for
p5-BSD-Resource>=0 in /usr/ports/devel/p5-BSD-Resource: No such file or
directory
pkg-static: Unable to access file
/usr/ports/www/mod_perl2/work/stage/usr/local/===>  Installing for
p5-BSD-Resource-1.2907: No such file or directory

... more of the same here

RE: mod_perl and apache 2.4

[GLG]

Well, it does in version 2.0.8. They are functions you can see clearly in
'modperl_io.h' and 'modperl_io.c'.

But I wasn't exactly planning on learning the intricacies of mod_perl so I
can try fixing this for myself. Rather, I was really hoping of getting some
help from someone who would know first-hand how to deal with it. Better yet
get an upgrade, but I am seriously running out of time. Several websites I
manage are depending on this to work, as I am forced to switch servers.





-Original Message-
From: Jie Gao [mailto:j@sydney.edu.au] 
Sent: Friday, May 08, 2015 9:59 PM
To: i...@3dnetproductions.com; 'mod_perl list'
Subject: RE: mod_perl and apache 2.4

mod_perl.so indeed does not have "modperl_io_perlio_restore_stdout", nor
"modperl_io_perlio_restore_stdin";
it does have "modperl_io_perlio_restore", which does not seem to be defined
anywhere in the source. Not sure why.

-JIie

From: GLG [i...@3dnetproductions.com]
Sent: Saturday, May 09, 2015 10:55 AM
To: 'mod_perl list'
Subject: RE: mod_perl and apache 2.4

It doesn't matter how I install mod_perl (dynamic or static. Also tried via
Webmin), the end result is always the same. This on FreeBSD 10.1

As soon as I add this line to httpd.conf

LoadModule perl_module libexec/apache22/mod_perl.so

and attempt to restart Apache, I get this...


apachectl restart

Now reading network conf in..  /etc/rc.conf
Now reading network conf in..  /etc/rc.conf
Performing sanity check on apache22 configuration:
httpd: Syntax error on line 107 of /usr/local/etc/apache22/httpd.conf:
Cannot load /usr/local/libexec/apache22/mod_perl.so into server:
/usr/local/libexec/apache22/mod_perl.so: Undefined symbol
"modperl_io_perlio_restore_stdout"
-

I have verified that mod_perl.so is in place. What on Earth is

'Undefined symbol "modperl_io_perlio_restore_stdout"'???


Is this really a mod_perl list?

Thank you,





-Original Message-
From: GLG [mailto:i...@3dnetproductions.com]
Sent: Friday, May 01, 2015 7:12 PM
To: 'mod_perl list'
Subject: RE: mod_perl and apache 2.4

Thanks André. Your info was useful.  I can't say that I solved this yet, but
I did find something strange.

But first, I no longer think there's an issue with libtool. It looks like
there's a fix running.

Secondly, I had to 'pkg install p5-BSD-Resource' dependency manually,
because the automatic installation by mod_perl2 didn't work.

And third, Can't really do 'make test' either because it has to run as a
priviledged user, and then Apache wants a non-priviledged user for the test
suite. Can't have both. So no dice.

But see below for where the real problem seems to be:

Short version:

Notice how gmake is installing mod_perl in ../ ../mach/5.18/ <--- correct
  but later tries to read from ../ ../5.18/mach/ <--- incorrect

Something is backward??? What is the right way to resolve this? I have been
at it way too long. Thanks,

--
Longer version:

[root@x /usr/ports/www/mod_perl2]# make install clean
===>  Staging for ap22-mod_perl2-2.0.8_2,3
===>   ap22-mod_perl2-2.0.8_2,3 depends on package: p5-BSD-Resource>=0 -
found
===>   ap22-mod_perl2-2.0.8_2,3 depends on file: /usr/local/sbin/apxs -
found
===>   ap22-mod_perl2-2.0.8_2,3 depends on file: /usr/local/bin/perl5.18.4 -
found
===>   Generating temporary packing list
gmake[1]: Entering directory '/usr/ports/www/mod_perl2/work/mod_perl-2.0.8'

... more stuff here

Installing
/usr/ports/www/mod_perl2/work/stage/usr/local/lib/perl5/site_perl/mach/5.18/

... more of the same here

 find:
/usr/ports/www/mod_perl2/work/stage/usr/local/lib/perl5/site_perl/5.18/mach/
auto: No such file or directory
> Compressing man pages (compress-man)
===>  Installing for ap22-mod_perl2-2.0.8_2,3
===>  Checking if ap22-mod_perl2 already installed
===>   Registering installation for ap22-mod_perl2-2.0.8_2,3
pkg-static: Unable to access file
/usr/ports/www/mod_perl2/work/stage/usr/local/===>
ap24-mod_perl2-2.0.8_2,3 depends on package: p5-BSD-Resource>=0 - not found:
No such file or directory
pkg-static: Unable to access file
/usr/ports/www/mod_perl2/work/stage/usr/local/===>Verifying install for
p5-BSD-Resource>=0 in /usr/ports/devel/p5-BSD-Resource: No such file or
directory
pkg-static: Unable to access file
/usr/ports/www/mod_perl2/work/stage/usr/local/===>  Installing for
p5-BSD-Resource-1.2907: No such file or directory

... more of the same here

RE: mod_perl and apache 2.4

[Jie Gao]

mod_perl.so indeed does not have "modperl_io_perlio_restore_stdout", nor 
"modperl_io_perlio_restore_stdin";
it does have "modperl_io_perlio_restore", which does not seem to be defined 
anywhere in the source. Not sure why.

-JIie

From: GLG [i...@3dnetproductions.com]
Sent: Saturday, May 09, 2015 10:55 AM
To: 'mod_perl list'
Subject: RE: mod_perl and apache 2.4

It doesn't matter how I install mod_perl (dynamic or static. Also tried via
Webmin), the end result is always the same. This on FreeBSD 10.1

As soon as I add this line to httpd.conf

LoadModule perl_module libexec/apache22/mod_perl.so

and attempt to restart Apache, I get this...


apachectl restart

Now reading network conf in..  /etc/rc.conf
Now reading network conf in..  /etc/rc.conf
Performing sanity check on apache22 configuration:
httpd: Syntax error on line 107 of /usr/local/etc/apache22/httpd.conf:
Cannot load /usr/local/libexec/apache22/mod_perl.so into server:
/usr/local/libexec/apache22/mod_perl.so: Undefined symbol
"modperl_io_perlio_restore_stdout"
-

I have verified that mod_perl.so is in place. What on Earth is

'Undefined symbol "modperl_io_perlio_restore_stdout"'???


Is this really a mod_perl list?

Thank you,





-Original Message-
From: GLG [mailto:i...@3dnetproductions.com]
Sent: Friday, May 01, 2015 7:12 PM
To: 'mod_perl list'
Subject: RE: mod_perl and apache 2.4

Thanks André. Your info was useful.  I can't say that I solved this yet, but
I did find something strange.

But first, I no longer think there's an issue with libtool. It looks like
there's a fix running.

Secondly, I had to 'pkg install p5-BSD-Resource' dependency manually,
because the automatic installation by mod_perl2 didn't work.

And third, Can't really do 'make test' either because it has to run as a
priviledged user, and then Apache wants a non-priviledged user for the test
suite. Can't have both. So no dice.

But see below for where the real problem seems to be:

Short version:

Notice how gmake is installing mod_perl in ../ ../mach/5.18/ <--- correct
  but later tries to read from ../ ../5.18/mach/ <--- incorrect

Something is backward??? What is the right way to resolve this? I have been
at it way too long. Thanks,

--
Longer version:

[root@x /usr/ports/www/mod_perl2]# make install clean
===>  Staging for ap22-mod_perl2-2.0.8_2,3
===>   ap22-mod_perl2-2.0.8_2,3 depends on package: p5-BSD-Resource>=0 -
found
===>   ap22-mod_perl2-2.0.8_2,3 depends on file: /usr/local/sbin/apxs -
found
===>   ap22-mod_perl2-2.0.8_2,3 depends on file: /usr/local/bin/perl5.18.4 -
found
===>   Generating temporary packing list
gmake[1]: Entering directory '/usr/ports/www/mod_perl2/work/mod_perl-2.0.8'

... more stuff here

Installing
/usr/ports/www/mod_perl2/work/stage/usr/local/lib/perl5/site_perl/mach/5.18/

... more of the same here

 find:
/usr/ports/www/mod_perl2/work/stage/usr/local/lib/perl5/site_perl/5.18/mach/
auto: No such file or directory
> Compressing man pages (compress-man)
===>  Installing for ap22-mod_perl2-2.0.8_2,3
===>  Checking if ap22-mod_perl2 already installed
===>   Registering installation for ap22-mod_perl2-2.0.8_2,3
pkg-static: Unable to access file
/usr/ports/www/mod_perl2/work/stage/usr/local/===>
ap24-mod_perl2-2.0.8_2,3 depends on package: p5-BSD-Resource>=0 - not found:
No such file or directory
pkg-static: Unable to access file
/usr/ports/www/mod_perl2/work/stage/usr/local/===>Verifying install for
p5-BSD-Resource>=0 in /usr/ports/devel/p5-BSD-Resource: No such file or
directory
pkg-static: Unable to access file
/usr/ports/www/mod_perl2/work/stage/usr/local/===>  Installing for
p5-BSD-Resource-1.2907: No such file or directory

... more of the same here

RE: mod_perl and apache 2.4

[GLG]

It doesn't matter how I install mod_perl (dynamic or static. Also tried via
Webmin), the end result is always the same. This on FreeBSD 10.1

As soon as I add this line to httpd.conf

LoadModule perl_module libexec/apache22/mod_perl.so

and attempt to restart Apache, I get this...


apachectl restart

Now reading network conf in..  /etc/rc.conf
Now reading network conf in..  /etc/rc.conf
Performing sanity check on apache22 configuration:
httpd: Syntax error on line 107 of /usr/local/etc/apache22/httpd.conf:
Cannot load /usr/local/libexec/apache22/mod_perl.so into server:
/usr/local/libexec/apache22/mod_perl.so: Undefined symbol
"modperl_io_perlio_restore_stdout"
-

I have verified that mod_perl.so is in place. What on Earth is

'Undefined symbol "modperl_io_perlio_restore_stdout"'???


Is this really a mod_perl list?

Thank you,





-Original Message-
From: GLG [mailto:i...@3dnetproductions.com] 
Sent: Friday, May 01, 2015 7:12 PM
To: 'mod_perl list'
Subject: RE: mod_perl and apache 2.4

Thanks André. Your info was useful.  I can't say that I solved this yet, but
I did find something strange.

But first, I no longer think there's an issue with libtool. It looks like
there's a fix running.

Secondly, I had to 'pkg install p5-BSD-Resource' dependency manually,
because the automatic installation by mod_perl2 didn't work. 

And third, Can't really do 'make test' either because it has to run as a
priviledged user, and then Apache wants a non-priviledged user for the test
suite. Can't have both. So no dice. 

But see below for where the real problem seems to be: 

Short version:

Notice how gmake is installing mod_perl in ../ ../mach/5.18/ <--- correct
  but later tries to read from ../ ../5.18/mach/ <--- incorrect

Something is backward??? What is the right way to resolve this? I have been
at it way too long. Thanks,

-- 
Longer version:

[root@x /usr/ports/www/mod_perl2]# make install clean
===>  Staging for ap22-mod_perl2-2.0.8_2,3
===>   ap22-mod_perl2-2.0.8_2,3 depends on package: p5-BSD-Resource>=0 -
found
===>   ap22-mod_perl2-2.0.8_2,3 depends on file: /usr/local/sbin/apxs -
found
===>   ap22-mod_perl2-2.0.8_2,3 depends on file: /usr/local/bin/perl5.18.4 -
found
===>   Generating temporary packing list
gmake[1]: Entering directory '/usr/ports/www/mod_perl2/work/mod_perl-2.0.8'

... more stuff here

Installing
/usr/ports/www/mod_perl2/work/stage/usr/local/lib/perl5/site_perl/mach/5.18/

... more of the same here

 find:
/usr/ports/www/mod_perl2/work/stage/usr/local/lib/perl5/site_perl/5.18/mach/
auto: No such file or directory
> Compressing man pages (compress-man)
===>  Installing for ap22-mod_perl2-2.0.8_2,3
===>  Checking if ap22-mod_perl2 already installed
===>   Registering installation for ap22-mod_perl2-2.0.8_2,3
pkg-static: Unable to access file
/usr/ports/www/mod_perl2/work/stage/usr/local/===>
ap24-mod_perl2-2.0.8_2,3 depends on package: p5-BSD-Resource>=0 - not found:
No such file or directory
pkg-static: Unable to access file
/usr/ports/www/mod_perl2/work/stage/usr/local/===>Verifying install for
p5-BSD-Resource>=0 in /usr/ports/devel/p5-BSD-Resource: No such file or
directory
pkg-static: Unable to access file
/usr/ports/www/mod_perl2/work/stage/usr/local/===>  Installing for
p5-BSD-Resource-1.2907: No such file or directory

... more of the same here

RE: mod_perl and apache 2.4

[GLG]

Thanks André. Your info was useful.  I can't say that I solved this yet, but
I did find something strange.

But first, I no longer think there's an issue with libtool. It looks like
there's a fix running.

Secondly, I had to 'pkg install p5-BSD-Resource' dependency manually,
because the automatic installation by mod_perl2 didn't work. 

And third, Can't really do 'make test' either because it has to run as a
priviledged user, and then Apache wants a non-priviledged user for the test
suite. Can't have both. So no dice. 

But see below for where the real problem seems to be: 

Short version:

Notice how gmake is installing mod_perl in ../ ../mach/5.18/ <--- correct
  but later tries to read from ../ ../5.18/mach/ <--- incorrect

Something is backward??? What is the right way to resolve this? I have been
at it way too long. Thanks,

-- 
Longer version:

[root@x /usr/ports/www/mod_perl2]# make install clean
===>  Staging for ap22-mod_perl2-2.0.8_2,3
===>   ap22-mod_perl2-2.0.8_2,3 depends on package: p5-BSD-Resource>=0 -
found
===>   ap22-mod_perl2-2.0.8_2,3 depends on file: /usr/local/sbin/apxs -
found
===>   ap22-mod_perl2-2.0.8_2,3 depends on file: /usr/local/bin/perl5.18.4 -
found
===>   Generating temporary packing list
gmake[1]: Entering directory '/usr/ports/www/mod_perl2/work/mod_perl-2.0.8'

... more stuff here

Installing
/usr/ports/www/mod_perl2/work/stage/usr/local/lib/perl5/site_perl/mach/5.18/

... more of the same here

 find:
/usr/ports/www/mod_perl2/work/stage/usr/local/lib/perl5/site_perl/5.18/mach/
auto: No such file or directory
> Compressing man pages (compress-man)
===>  Installing for ap22-mod_perl2-2.0.8_2,3
===>  Checking if ap22-mod_perl2 already installed
===>   Registering installation for ap22-mod_perl2-2.0.8_2,3
pkg-static: Unable to access file
/usr/ports/www/mod_perl2/work/stage/usr/local/===>
ap24-mod_perl2-2.0.8_2,3 depends on package: p5-BSD-Resource>=0 - not found:
No such file or directory
pkg-static: Unable to access file
/usr/ports/www/mod_perl2/work/stage/usr/local/===>Verifying install for
p5-BSD-Resource>=0 in /usr/ports/devel/p5-BSD-Resource: No such file or
directory
pkg-static: Unable to access file
/usr/ports/www/mod_perl2/work/stage/usr/local/===>  Installing for
p5-BSD-Resource-1.2907: No such file or directory

... more of the same here

Re: mod_perl and apache 2.4

[André Warnier]

Hi.

I honestly don't know if this will help you, because I have no idea about 
FreeBSD.
But what I can tell you, is that I am running Apache 2.2 and mod_perl 2 succesfully on 
multiple servers, under various versions of Windows and under various versions of Linux, 
without any problems whatsoever.
So it looks at least that if you are having a problem, it should be something specific to 
the FreeBSD environment that you are using, and not about the Apache 2.2 / mod_perl 2 
combination in general.



GLG wrote:

Thanks everyone for earlier replies,

I now have Apache22 installed, but I am unable to start it with mod_perl2.


From my research, I am being led to believe that my mod_perl2 installation

may be faulty, due to the fact that Libtool needs to be patched, as it
incorrectly identifies FreeBSD 10 as FreeBSD 1.x, and that can be the source
of my problems (Undefined symbol "modperl_io_perlio_restore_stdout").

This information is several months old however. Does anyone know if the
above is fixed with Libtool 2.4.6? Can anyone here successfully load
mod_perl.so into apache22, or am I beating a dead horse?  


Thanks again,
GLG


* GLG  wrote:


Date: Thu, 16 Apr 2015 10:22:23 -0400
From: GLG 
To: modperl@perl.apache.org
Subject: mod_perl and apache 2.4
X-Mailer: Microsoft Office Outlook 12.0

Hello List, 


I am new here. In the process of moving several websites to a new server
running FreeBSD 10 and Apache 2.4. This needs to happen quickly. 


Unless I am mistaken, it would appear that there is currently no solution

as

far as running Perl with Apache 2.4 via mod_perl 2.0.8 (or is there a
version 2.0.9 out?). 


If indeed that is the case, then I must downgrade to a previous version of
Apache. But before I do, I'd like confirmation that my assumptions are
correct. Hopefully someone can answer this or suggest a better

alternative.

I've tried applying a previously released patch, and I've also tried

faking
it as described here. 


http://lists.freebsd.org/pipermail/freebsd-ports/2014-August/094405.html

But in both cases, mod_perl will not build. Please see partial output

below.


Thank you,
Gina


/usr/ports/www/mod_perl2 # make build
===>   ap24-mod_perl2-2.0.8_2,3 depends on package: p5-BSD-Resource>=0 -

not

found
===>Verifying install for p5-BSD-Resource>=0 in
/usr/ports/devel/p5-BSD-Resource
===>  Installing for p5-BSD-Resource-1.2907
===>   p5-BSD-Resource-1.2907 depends on file: /usr/local/bin/perl5.18.4 -
found
===>  Checking if p5-BSD-Resource already installed
===>   Registering installation for p5-BSD-Resource-1.2907 as automatic
pkg-static: Unable to access file


/usr/ports/devel/p5-BSD-Resource/work/stage/usr/local/lib/perl5/site_perl/5.

18/mach/BSD/Resource.pm: No such file or directory
pkg-static: Unable to access file


/usr/ports/devel/p5-BSD-Resource/work/stage/usr/local/lib/perl5/site_perl/5.

18/mach/auto/BSD/Resource/.packlist: No such file or directory
pkg-static: Unable to access file


/usr/ports/devel/p5-BSD-Resource/work/stage/usr/local/lib/perl5/site_perl/5.

18/mach/auto/BSD/Resource/Resource.so: No such file or directory
pkg-static: Unable to access file


/usr/ports/devel/p5-BSD-Resource/work/stage/usr/local/lib/perl5/site_perl/5.

18/mach/auto/BSD/Resource/_find_prio.al: No such file or directory



__
 * * Interactive Multimedia - Internet Management * *
  * * Virtual Reality  -  Application Programming  * *
   * 3D Net Productions 3dnetproductions.com *

RE: mod_perl and apache 2.4

[GLG]

Thanks everyone for earlier replies,

I now have Apache22 installed, but I am unable to start it with mod_perl2.

>From my research, I am being led to believe that my mod_perl2 installation
may be faulty, due to the fact that Libtool needs to be patched, as it
incorrectly identifies FreeBSD 10 as FreeBSD 1.x, and that can be the source
of my problems (Undefined symbol "modperl_io_perlio_restore_stdout").

This information is several months old however. Does anyone know if the
above is fixed with Libtool 2.4.6? Can anyone here successfully load
mod_perl.so into apache22, or am I beating a dead horse?  

Thanks again,
GLG


* GLG  wrote:

> Date: Thu, 16 Apr 2015 10:22:23 -0400
> From: GLG 
> To: modperl@perl.apache.org
> Subject: mod_perl and apache 2.4
> X-Mailer: Microsoft Office Outlook 12.0
> 
> Hello List, 
> 
> I am new here. In the process of moving several websites to a new server
> running FreeBSD 10 and Apache 2.4. This needs to happen quickly. 
> 
> Unless I am mistaken, it would appear that there is currently no solution
as
> far as running Perl with Apache 2.4 via mod_perl 2.0.8 (or is there a
> version 2.0.9 out?). 
> 
> If indeed that is the case, then I must downgrade to a previous version of
> Apache. But before I do, I'd like confirmation that my assumptions are
> correct. Hopefully someone can answer this or suggest a better
alternative.
> 
> I've tried applying a previously released patch, and I've also tried
faking
> it as described here. 
> 
> http://lists.freebsd.org/pipermail/freebsd-ports/2014-August/094405.html
> 
> But in both cases, mod_perl will not build. Please see partial output
below.
> 
> 
> Thank you,
> Gina
> 
> 
> /usr/ports/www/mod_perl2 # make build
> ===>   ap24-mod_perl2-2.0.8_2,3 depends on package: p5-BSD-Resource>=0 -
not
> found
> ===>Verifying install for p5-BSD-Resource>=0 in
> /usr/ports/devel/p5-BSD-Resource
> ===>  Installing for p5-BSD-Resource-1.2907
> ===>   p5-BSD-Resource-1.2907 depends on file: /usr/local/bin/perl5.18.4 -
> found
> ===>  Checking if p5-BSD-Resource already installed
> ===>   Registering installation for p5-BSD-Resource-1.2907 as automatic
> pkg-static: Unable to access file
>
/usr/ports/devel/p5-BSD-Resource/work/stage/usr/local/lib/perl5/site_perl/5.
> 18/mach/BSD/Resource.pm: No such file or directory
> pkg-static: Unable to access file
>
/usr/ports/devel/p5-BSD-Resource/work/stage/usr/local/lib/perl5/site_perl/5.
> 18/mach/auto/BSD/Resource/.packlist: No such file or directory
> pkg-static: Unable to access file
>
/usr/ports/devel/p5-BSD-Resource/work/stage/usr/local/lib/perl5/site_perl/5.
> 18/mach/auto/BSD/Resource/Resource.so: No such file or directory
> pkg-static: Unable to access file
>
/usr/ports/devel/p5-BSD-Resource/work/stage/usr/local/lib/perl5/site_perl/5.
> 18/mach/auto/BSD/Resource/_find_prio.al: No such file or directory
> 
> 
> 
> __
>  * * Interactive Multimedia - Internet Management * *
>   * * Virtual Reality  -  Application Programming  * *
>* 3D Net Productions 3dnetproductions.com *
> 
> 
> 

Re: mod_perl Segmentation fault with ModProxyHtml

[Pashmak Pahsmakian]

Dear all,Does anybody have a solution for this problem.It seems to be a serious 
modperl problem. I have also seen some related problems in other modules using 
modperl.Thanks for any help. 


 On Monday, April 13, 2015 2:28 PM, Pashmak Pahsmakian 
 wrote:
   

 Hello,
I am using httpd 2.2.15(worker MPM), perl 5.20.1 with modperl 2.0.8 to use 
ProxyPerlHtml-3.6 as an OutputFilter for substitution.When I try to test my 
system using apache benchmark and when the concurrency(-c) option is high, I 
receive a Segmentation fault which seems to be a memory problem. I used these 
options to compile mod_perl and ModProxyPerlHtml:
build mod_perl:
/usr/perl-5.20.1/bin/perl Makefile.PL MP_APXS=/usr/local/apache2.2.15/bin/apxs 
MP_APR_CONFIG=/usr/local/apr_apu-2.2.15/bin/apr-1-config 
MP_APU_CONFIG=/usr/local/apr_apu-2.2.15/bin/apu-1-config 
PREFIX=/usr/mod_perl-2.0.8

compile ModProxyPerlHtml-3.6
export PERL5LIB=/usr/mod_perl-2.0.8/lib/site_perl/
perl Makefile.PL

I have attached my apache config file and my apache error_log file with 
backtrace.

"uname -a" output:
Linux 3.2.0-4-amd64 #1 SMP Debian 3.2.60-1+deb7u1 x86_64 GNU/Linux

"perl -V" output:
Summary of my perl5 (revision 5 version 20 subversion 1) configuration:

  Platform:
    osname=linux, osvers=3.2.0-4-amd64, archname=x86_64-linux-thread-multi
    uname='linux parswaf 3.2.0-4-amd64 #1 smp debian 3.2.60-1+deb7u1 x86_64 
gnulinux '
    config_args='-des -Dusethreads -Dprefix=/usr/perl-5.20.1 -Duseshrplib'
    hint=recommended, useposix=true, d_sigaction=define
    useithreads=define, usemultiplicity=define
    use64bitint=define, use64bitall=define, uselongdouble=undef
    usemymalloc=n, bincompat5005=undef
  Compiler:
    cc='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -fwrapv -fno-strict-aliasing 
-pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE 
-D_FILE_OFFSET_BITS=64',
    optimize='-O2',
    cppflags='-D_REENTRANT -D_GNU_SOURCE -fwrapv -fno-strict-aliasing -pipe 
-fstack-protector -I/usr/local/include'
    ccversion='', gccversion='4.7.2', gccosandvers=''
    intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
    ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', 
lseeksize=8
    alignbytes=8, prototype=define
  Linker and Libraries:
    ld='cc', ldflags =' -fstack-protector -L/usr/local/lib'
    libpth=/usr/local/lib /usr/lib/gcc/x86_64-linux-gnu/4.7/include-fixed 
/usr/include/x86_64-linux-gnu /usr/lib /lib/x86_64-linux-gnu /lib/../lib 
/usr/lib/x86_64-linux-gnu /usr/lib/../lib /lib
    libs=-lnsl -ldl -lm -lcrypt -lutil -lpthread -lc
    perllibs=-lnsl -ldl -lm -lcrypt -lutil -lpthread -lc
    libc=libc-2.13.so, so=so, useshrplib=true, libperl=libperl.so
    gnulibc_version='2.13'
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E 
-Wl,-rpath,/usr/perl-5.20.1/lib/5.20.1/x86_64-linux-thread-multi/CORE'
    cccdlflags='-fPIC', lddlflags='-shared -O2 -L/usr/local/lib 
-fstack-protector'


Characteristics of this binary (from libperl):
  Compile-time options: HAS_TIMES MULTIPLICITY PERLIO_LAYERS
    PERL_DONT_CREATE_GVSV
    PERL_HASH_FUNC_ONE_AT_A_TIME_HARD
    PERL_IMPLICIT_CONTEXT PERL_MALLOC_WRAP
    PERL_NEW_COPY_ON_WRITE PERL_PRESERVE_IVUV
    USE_64_BIT_ALL USE_64_BIT_INT USE_ITHREADS
    USE_LARGE_FILES USE_LOCALE USE_LOCALE_COLLATE
    USE_LOCALE_CTYPE USE_LOCALE_NUMERIC USE_PERLIO
    USE_PERL_ATOF USE_REENTRANT_API
  Built under linux
  Compiled at Apr 12 2015 09:26:10
  @INC:
    /usr/perl-5.20.1/lib/site_perl/5.20.1/x86_64-linux-thread-multi
    /usr/perl-5.20.1/lib/site_perl/5.20.1
    /usr/perl-5.20.1/lib/5.20.1/x86_64-linux-thread-multi
    /usr/perl-5.20.1/lib/5.20.1
Thanks for any consideration.




  

Re: mod_perl and apache 2.4

[Jie Gao]

Redhat Enterprise Linux 7 does not seem to have mod_perl in the core 
distribution channel.

Regards,

Jie 

* GLG  wrote:

> Date: Thu, 16 Apr 2015 10:22:23 -0400
> From: GLG 
> To: modperl@perl.apache.org
> Subject: mod_perl and apache 2.4
> X-Mailer: Microsoft Office Outlook 12.0
> 
> Hello List, 
> 
> I am new here. In the process of moving several websites to a new server
> running FreeBSD 10 and Apache 2.4. This needs to happen quickly. 
> 
> Unless I am mistaken, it would appear that there is currently no solution as
> far as running Perl with Apache 2.4 via mod_perl 2.0.8 (or is there a
> version 2.0.9 out?). 
> 
> If indeed that is the case, then I must downgrade to a previous version of
> Apache. But before I do, I'd like confirmation that my assumptions are
> correct. Hopefully someone can answer this or suggest a better alternative.
> 
> I've tried applying a previously released patch, and I've also tried faking
> it as described here. 
> 
> http://lists.freebsd.org/pipermail/freebsd-ports/2014-August/094405.html
> 
> But in both cases, mod_perl will not build. Please see partial output below.
> 
> 
> Thank you,
> Gina
> 
> 
> /usr/ports/www/mod_perl2 # make build
> ===>   ap24-mod_perl2-2.0.8_2,3 depends on package: p5-BSD-Resource>=0 - not
> found
> ===>Verifying install for p5-BSD-Resource>=0 in
> /usr/ports/devel/p5-BSD-Resource
> ===>  Installing for p5-BSD-Resource-1.2907
> ===>   p5-BSD-Resource-1.2907 depends on file: /usr/local/bin/perl5.18.4 -
> found
> ===>  Checking if p5-BSD-Resource already installed
> ===>   Registering installation for p5-BSD-Resource-1.2907 as automatic
> pkg-static: Unable to access file
> /usr/ports/devel/p5-BSD-Resource/work/stage/usr/local/lib/perl5/site_perl/5.
> 18/mach/BSD/Resource.pm: No such file or directory
> pkg-static: Unable to access file
> /usr/ports/devel/p5-BSD-Resource/work/stage/usr/local/lib/perl5/site_perl/5.
> 18/mach/auto/BSD/Resource/.packlist: No such file or directory
> pkg-static: Unable to access file
> /usr/ports/devel/p5-BSD-Resource/work/stage/usr/local/lib/perl5/site_perl/5.
> 18/mach/auto/BSD/Resource/Resource.so: No such file or directory
> pkg-static: Unable to access file
> /usr/ports/devel/p5-BSD-Resource/work/stage/usr/local/lib/perl5/site_perl/5.
> 18/mach/auto/BSD/Resource/_find_prio.al: No such file or directory
> 
> 
> 
> __
>  * * Interactive Multimedia - Internet Management * *
>   * * Virtual Reality  -  Application Programming  * *
>* 3D Net Productions 3dnetproductions.com *
> 
> 
> 

Re: mod_perl and apache 2.4

[Lathan Bidwell]

I know it doesn't help you, but Debian has been shipping with apache 2.4
and mod_perl working since last year.

Of course with Debian, they compile it and stuff it into a package, so we
avoid compilation problems.


On Thu, Apr 16, 2015 at 10:27 AM, Kevin A. McGrail 
wrote:

> On 4/16/2015 10:22 AM, GLG wrote:
>
>> Unless I am mistaken, it would appear that there is currently no solution
>> as
>> far as running Perl with Apache 2.4 via mod_perl 2.0.8 (or is there a
>> version 2.0.9 out?).
>>
>
> That is currently the case.  I believe there is an SVN version that will
> build and work but unless you have a driving need for a feature in 2.4, 2.2
> is your better bet right now.
>
> Though I noticed last week CentOS 7 shipped with 2.4 and no mod_perl so
> hopefully we can get that mod_perl 2.4 compatible release soon and they'll
> retrofit it for 2.4 for those users who rely on package distros.
>
> Regards,
> KAM
>
>
>

Re: mod_perl and apache 2.4

[Kevin A. McGrail]

On 4/16/2015 10:22 AM, GLG wrote:

Unless I am mistaken, it would appear that there is currently no solution as
far as running Perl with Apache 2.4 via mod_perl 2.0.8 (or is there a
version 2.0.9 out?).


That is currently the case.  I believe there is an SVN version that will 
build and work but unless you have a driving need for a feature in 2.4, 
2.2 is your better bet right now.


Though I noticed last week CentOS 7 shipped with 2.4 and no mod_perl so 
hopefully we can get that mod_perl 2.4 compatible release soon and 
they'll retrofit it for 2.4 for those users who rely on package distros.


Regards,
KAM

Re: mod_perl for multi-process file processing?

[Patton, Billy N]

You will find that when you share the memory the hashes are not copied to each 
thread.
The docs are a little misleading.
On Feb 3, 2015, at 11:54 AM, Alan Raetz 
mailto:alanra...@gmail.com>> wrote:

Thanks for all the input. I was considering threads, but according to how I 
read the perlthreadtut 
(http://search.cpan.org/~rjbs/perl-5.18.4/pod/perlthrtut.pod#Threads_And_Data), 
quote: "When a new Perl thread is created, all the data associated with the 
current thread is copied to the new thread, and is subsequently private to that 
new thread" So in my application, each thread would get the entire memory 
footprint copied. So although the data is "shared" in terms of application 
usage, in terms of physical memory limitations, I would quickly use up the 
machine memory. If you're reading/writing files, this may not be a significant 
difference, but with the way this app is structured now, I think it may be.

One of my thoughts as far as reducing the impact of request overhead was to 
"bundle" requests, such that a single request is getting multiple tasks.
​
I will look into some of these suggestions more, thanks again.

Re: mod_perl for multi-process file processing?

[Alan Raetz]

Thanks for all the input. I was considering threads, but according to how I
read the perlthreadtut (
http://search.cpan.org/~rjbs/perl-5.18.4/pod/perlthrtut.pod#Threads_And_Data),
quote: "When a new Perl thread is created, all the data associated with the
current thread is copied to the new thread, and is subsequently private to
that new thread" So in my application, each thread would get the entire
memory footprint copied. So although the data is "shared" in terms of
application usage, in terms of physical memory limitations, I would quickly
use up the machine memory. If you're reading/writing files, this may not be
a significant difference, but with the way this app is structured now, I
think it may be.

One of my thoughts as far as reducing the impact of request overhead was to
"bundle" requests, such that a single request is getting multiple tasks.
​
I will look into some of these suggestions more, thanks again.

Re: mod_perl for multi-process file processing?

[Perrin Harkins]

I agree, either threads or Parallel::ForkManager, depending on your
platform and your perl, will be a lot faster than mod_perl for this. Of
course there might be other reasons to use mod_perl, e.g. it's useful to
have this available as a remote service, or you want to call this
frequently for small jobs throughout the day without needing to reload the
data.

- Perrin

On Tue, Feb 3, 2015 at 7:42 AM, Patton, Billy N 
wrote:

> Unless I’m entirely wrong it appears that you want to use shared threaded
> memory.
> This would allow you to keep out of apache altogether.
> Here is an example of using threads that I worked out using shared memory.
> We took a 4 hour task, serial, and turned it into 5 minutes with threads.
> This worked extremely well for me.  I wasn’t using large hashes, but I was
> hundreds of files, per thread, with 30k lines per file.
> #!/usr/bin/env perl -w
> use strict;
> use warnings;
> use Data::Dumper;
> $Data::Dumper::Indent = 1;
> $Data::Dumper::Sortkeys = 1;
> $Data::Dumper::Deepcopy = 1;
> use threads;
> use threads::shared;
> use constant  MAX_TRIES => 5;
>
> sub sub_threads($$$);
>
> my $switch= undef;
> my $hash  = undef;
> my $gsx   = undef;
> my $cnt   = 5;
> my %switches= ( 'A' => { 'b' => undef , 'c' => undef, 'd' => undef },
> 'B' => { 'b' => undef , 'c' => undef, 'd' => undef },
> 'C' => { 'b' => undef , 'c' => undef, 'd' => undef },
> 'D' => { 'b' => undef , 'c' => undef, 'd' => undef },
> 'E' => { 'b' => undef , 'c' => undef, 'd' => undef },
>);
> my %threads : shared  = ();
>
> ##
> ## create the threads
> #
> while (($switch,$hash) = each %switches) {
>   unless (exists $threads{$switch}) {
> my %h : shared;
> $threads{$switch} = \%h;
>   }
>   while (($gsx, $_) = each %$hash) {
> unless (exists $threads{$switch}{$gsx}) {
>   my %h : shared;
>   $threads{$switch}{$gsx} = \%h;
> }
> unless (exists $threads{$switch}{$gsx}{'messages'}) {
>   my @h : shared;
>   $threads{$switch}->{$gsx}->{'messages'} = \@h;
> }
> $hash->{$gsx}->{'thread'} =
> threads->create(\&sub_threads,\$switch,\$gsx,\$cnt);
> $hash->{$gsx}->{'tries'}  = 1;
> $cnt += 5;
>   }
> }
>
> #print Dumper \%threads;
> #print Dumper \%switches;
>
> ##
> ## endless loop to run while threads are still running
> ##
> $cnt = 1;
> while ($cnt) {
>   $cnt = 0;
>   while (($switch,$hash) = each %switches) {
> while (($gsx, $_) = each %$hash) {
>   if ($hash->{$gsx}->{'thread'}->is_running()) {
> $cnt = 1;
> #print "$switch->$gsx is running\n";
>   } else {
> #print "$switch->$gsx is NOT running\n";
> #print "  Reason for failure : \n";
> #print ' ' .  join('\n' ,
> @{$threads{$switch}->{$gsx}->{'messages'}}) . "\n";
> if ($hash->{$gsx}->{'tries'} < MAX_TRIES) {
> #  print "  max tries not reached for $switch->$gsx, will be
> trying again!\n";
>   $hash->{$gsx}->{'tries'}++;
>   $hash->{$gsx}->{'thread'} =
> threads->create(\&sub_threads,\$switch,\$gsx,\$cnt);
> } else {
>   print "send email! $switch->$gsx\n";
> }
>   }
> }
> sleep 2;
>   }
> }
>
> #print Dumper \%threads;
> #print Dumper \%switches;
>
>
> sub sub_threads($$$) {
>   my $ptr_switch  = shift;
>   my $ptr_gsx = shift;
>   my $ptr_tNum= shift;
>   sleep $$ptr_tNum;
>   {
> lock(%threads);
> push @{$threads{$$ptr_switch}->{$$ptr_gsx}->{'messages'}} , "Leaving
> thread $$ptr_switch->$$ptr_gsx";
> #$threads{$$ptr_switch}->{$ptr_gsx}->{'messages'} = "Leaving thread
> $$ptr_switch->$$ptr_gsx";
> # locke freed at end oc scope
>   }
>   return 0;
> }
>
> On Feb 2, 2015, at 10:11 PM, Alan Raetz  alanra...@gmail.com>> wrote:
>
> So I have a perl application that upon startup loads about ten perl hashes
> (some of them complex) from files. This takes up a few GB of memory and
> about 5 minutes. It then iterates through some cases and reads from (never
> writes) these perl hashes. To process all our cases, it takes about 3 hours
> (millions of cases). We would like to speed up this process. I am thinking
> this is an ideal application of mod_perl because it would allow multiple
> processes but share memory.
>
> The scheme would be to load the hashes on apache startup and have a master
> program send requests with each case and apache children will use the
> shared hashes.
>
> I just want to verify some of the details about variable sharing.  Would
> the following setup work (oversimplified, but you get the idea…):
>
> In a file Data.pm, which I would use() in my Apache startup.pl<
> http://startup.pl/>, I would load the perl hashes and have hash
> references that would be retrieved with class methods:
>
> package Data;
>
> my %big_hash;
>
> open(FILE,"file.txt");
>
> while (  ) {
>
>   … code ….
>
> 

Re: mod_perl for multi-process file processing?

[Perrin Harkins]

Cache::FastMmap is a great module for sharing read/write data, but it can't
compete with the speed of loading it all into memory before forking as Alan
said he plans to do.

- Perrin

On Tue, Feb 3, 2015 at 2:05 AM, Cosimo Streppone 
wrote:

> Alan Raetz wrote:
>
>  So I have a perl application that upon startup loads about ten perl
>> hashes (some of them complex) from files. This takes up a few GB of
>> memory and about 5 minutes. It then iterates through some cases and
>> reads from (never writes) these perl hashes. To process all our cases,
>> it takes about 3 hours (millions of cases). We would like to speed up
>> this process. I am thinking this is an ideal application of mod_perl
>> because it would allow multiple processes but share memory.
>>
>
> Sure you could use modperl for this.
> I would also consider at least these alternatives:
>
> - use Cache::FastMmap, https://metacpan.org/pod/Cache::FastMmap
>   Load up your data with a loader script, and forget about it.
>   Cache::FastMmap also works with modperl.
>
> - use a network server, like memcached or redis to store your
>   read-only data, and use a lightweight network protocol (on localhost)
>   to get the data.
>
> In both cases, reading from multiple processes will not be a problem.
> The cheapest solution for the consumer part (the "cases" above)
> would be to use a command like "parallel" to fire up as many copies
> of your consumer script as you can afford.
>
> Hope this helps,
>
> --
> Cosimo
>
>

Re: mod_perl for multi-process file processing?

[Patton, Billy N]

Unless I’m entirely wrong it appears that you want to use shared threaded 
memory.
This would allow you to keep out of apache altogether.
Here is an example of using threads that I worked out using shared memory.
We took a 4 hour task, serial, and turned it into 5 minutes with threads.
This worked extremely well for me.  I wasn’t using large hashes, but I was 
hundreds of files, per thread, with 30k lines per file.
#!/usr/bin/env perl -w
use strict;
use warnings;
use Data::Dumper;
$Data::Dumper::Indent = 1;
$Data::Dumper::Sortkeys = 1;
$Data::Dumper::Deepcopy = 1;
use threads;
use threads::shared;
use constant  MAX_TRIES => 5;

sub sub_threads($$$);

my $switch= undef;
my $hash  = undef;
my $gsx   = undef;
my $cnt   = 5;
my %switches= ( 'A' => { 'b' => undef , 'c' => undef, 'd' => undef },
'B' => { 'b' => undef , 'c' => undef, 'd' => undef },
'C' => { 'b' => undef , 'c' => undef, 'd' => undef },
'D' => { 'b' => undef , 'c' => undef, 'd' => undef },
'E' => { 'b' => undef , 'c' => undef, 'd' => undef },
   );
my %threads : shared  = ();

##
## create the threads
#
while (($switch,$hash) = each %switches) {
  unless (exists $threads{$switch}) {
my %h : shared;
$threads{$switch} = \%h;
  }
  while (($gsx, $_) = each %$hash) {
unless (exists $threads{$switch}{$gsx}) {
  my %h : shared;
  $threads{$switch}{$gsx} = \%h;
}
unless (exists $threads{$switch}{$gsx}{'messages'}) {
  my @h : shared;
  $threads{$switch}->{$gsx}->{'messages'} = \@h;
}
$hash->{$gsx}->{'thread'} = 
threads->create(\&sub_threads,\$switch,\$gsx,\$cnt);
$hash->{$gsx}->{'tries'}  = 1;
$cnt += 5;
  }
}

#print Dumper \%threads;
#print Dumper \%switches;

##
## endless loop to run while threads are still running
##
$cnt = 1;
while ($cnt) {
  $cnt = 0;
  while (($switch,$hash) = each %switches) {
while (($gsx, $_) = each %$hash) {
  if ($hash->{$gsx}->{'thread'}->is_running()) {
$cnt = 1;
#print "$switch->$gsx is running\n";
  } else {
#print "$switch->$gsx is NOT running\n";
#print "  Reason for failure : \n";
#print ' ' .  join('\n' , 
@{$threads{$switch}->{$gsx}->{'messages'}}) . "\n";
if ($hash->{$gsx}->{'tries'} < MAX_TRIES) {
#  print "  max tries not reached for $switch->$gsx, will be trying 
again!\n";
  $hash->{$gsx}->{'tries'}++;
  $hash->{$gsx}->{'thread'} = 
threads->create(\&sub_threads,\$switch,\$gsx,\$cnt);
} else {
  print "send email! $switch->$gsx\n";
}
  }
}
sleep 2;
  }
}

#print Dumper \%threads;
#print Dumper \%switches;


sub sub_threads($$$) {
  my $ptr_switch  = shift;
  my $ptr_gsx = shift;
  my $ptr_tNum= shift;
  sleep $$ptr_tNum;
  {
lock(%threads);
push @{$threads{$$ptr_switch}->{$$ptr_gsx}->{'messages'}} , "Leaving thread 
$$ptr_switch->$$ptr_gsx";
#$threads{$$ptr_switch}->{$ptr_gsx}->{'messages'} = "Leaving thread 
$$ptr_switch->$$ptr_gsx";
# locke freed at end oc scope
  }
  return 0;
}

On Feb 2, 2015, at 10:11 PM, Alan Raetz 
mailto:alanra...@gmail.com>> wrote:

So I have a perl application that upon startup loads about ten perl hashes 
(some of them complex) from files. This takes up a few GB of memory and about 5 
minutes. It then iterates through some cases and reads from (never writes) 
these perl hashes. To process all our cases, it takes about 3 hours (millions 
of cases). We would like to speed up this process. I am thinking this is an 
ideal application of mod_perl because it would allow multiple processes but 
share memory.

The scheme would be to load the hashes on apache startup and have a master 
program send requests with each case and apache children will use the shared 
hashes.

I just want to verify some of the details about variable sharing.  Would the 
following setup work (oversimplified, but you get the idea…):

In a file Data.pm, which I would use() in my Apache 
startup.pl, I would load the perl hashes and have hash 
references that would be retrieved with class methods:

package Data;

my %big_hash;

open(FILE,"file.txt");

while (  ) {

  … code ….

  $big_hash{ $key } = $value;
}

sub get_big_hashref {   return \%big_hash; }



And so in the apache request handler, the code would be something like:

use Data.pm;

my $hashref = Data::get_big_hashref();

…. code to access $hashref data with request parameters…..



The idea is the HTTP request/response will contain the relevant input/output 
for each case… and the master client program will collect these and 
concatentate the final output from all the requests.

So any issues/suggestions with this approach? I am facing a non-trivial task of 
refactoring the existing code to work in this framework, so just wanted to get 
some feedback before I invest more t

Re: mod_perl for multi-process file processing?

[Cosimo Streppone]

Alan Raetz wrote:


So I have a perl application that upon startup loads about ten perl
hashes (some of them complex) from files. This takes up a few GB of
memory and about 5 minutes. It then iterates through some cases and
reads from (never writes) these perl hashes. To process all our cases,
it takes about 3 hours (millions of cases). We would like to speed up
this process. I am thinking this is an ideal application of mod_perl
because it would allow multiple processes but share memory.


Sure you could use modperl for this.
I would also consider at least these alternatives:

- use Cache::FastMmap, https://metacpan.org/pod/Cache::FastMmap
  Load up your data with a loader script, and forget about it.
  Cache::FastMmap also works with modperl.

- use a network server, like memcached or redis to store your
  read-only data, and use a lightweight network protocol (on localhost)
  to get the data.

In both cases, reading from multiple processes will not be a problem.
The cheapest solution for the consumer part (the "cases" above)
would be to use a command like "parallel" to fire up as many copies
of your consumer script as you can afford.

Hope this helps,

--
Cosimo

Re: mod_perl for multi-process file processing?

[Dr James Smith]

Alan/Alexandr,

There will always be an overhead with using a webserver to do this - 
even using mod_perl.


Assumiptions:
*from what you are saying that there is no actual website 
involved but you want to use mod_perl to cache data for an offline process;

*One set of data is used once and once only for a run?

Pros:
*Make sure you use your module in startup so that each child 
thread uses the same memory not generating a copy of the data;
*If you use something like curl multi as the fetcher you can 
write a simple parallel fetching queue to get the data - great if you 
have a multi-core box;


Cons:
*There is an overhead of using HTTP protocol webserver - if you 
aren't going to gain much from the parallelization of processes above 
you may find that writing a simple script which loops over all data 
would be more efficient...
*In your case we are probably looking at about 10ms (or less) 
the apache/http round tripping will probably take much more time than 
the actual processing...


On 03/02/2015 05:02, Alexandr Evstigneev wrote:
Pre-loading is good, but what you need, I belive, is Storable module. 
If your files contains parsed data (hashes) just store them as 
serialized. If they containing raw data, need to be parsed, you may 
pre-parse, serialize it and store as binary files.

Storable is written in C and works very fast.


2015-02-03 7:11 GMT+03:00 Alan Raetz >:


So I have a perl application that upon startup loads about ten
perl hashes (some of them complex) from files. This takes up a few
GB of memory and about 5 minutes. It then iterates through some
cases and reads from (never writes) these perl hashes. To process
all our cases, it takes about 3 hours (millions of cases). We
would like to speed up this process. I am thinking this is an
ideal application of mod_perl because it would allow multiple
processes but share memory.

The scheme would be to load the hashes on apache startup and have
a master program send requests with each case and apache children
will use the shared hashes.

I just want to verify some of the details about variable sharing. 
Would the following setup work (oversimplified, but you get the

idea…):

In a file Data.pm, which I would use() in my Apache startup.pl
, I would load the perl hashes and have hash
references that would be retrieved with class methods:

package Data;

my %big_hash;

open(FILE,"file.txt");

while (  ) {

  … code ….

  $big_hash{ $key } = $value;
}

sub get_big_hashref {   return \%big_hash; }



And so in the apache request handler, the code would be something
like:

use Data.pm;

my $hashref = Data::get_big_hashref();

…. code to access $hashref data with request parameters…..



The idea is the HTTP request/response will contain the relevant
input/output for each case… and the master client program will
collect these and concatentate the final output from all the requests.

So any issues/suggestions with this approach? I am facing a
non-trivial task of refactoring the existing code to work in this
framework, so just wanted to get some feedback before I invest
more time into this...

I am planning on using mod_perl 2.07 on a linux machine.

Thanks in advance, Alan






---
This email has been checked for viruses by Avast antivirus software.
http://www.avast.com



--
The Wellcome Trust Sanger Institute is operated by Genome Research 
Limited, a charity registered in England with number 1021457 and a 
company registered in England with number 2742969, whose registered 
office is 215 Euston Road, London, NW1 2BE. 

Re: mod_perl for multi-process file processing?

[Alexandr Evstigneev]

Pre-loading is good, but what you need, I belive, is Storable module. If
your files contains parsed data (hashes) just store them as serialized. If
they containing raw data, need to be parsed, you may pre-parse, serialize
it and store as binary files.
Storable is written in C and works very fast.


2015-02-03 7:11 GMT+03:00 Alan Raetz :

> So I have a perl application that upon startup loads about ten perl hashes
> (some of them complex) from files. This takes up a few GB of memory and
> about 5 minutes. It then iterates through some cases and reads from (never
> writes) these perl hashes. To process all our cases, it takes about 3 hours
> (millions of cases). We would like to speed up this process. I am thinking
> this is an ideal application of mod_perl because it would allow multiple
> processes but share memory.
>
> The scheme would be to load the hashes on apache startup and have a master
> program send requests with each case and apache children will use the
> shared hashes.
>
> I just want to verify some of the details about variable sharing.  Would
> the following setup work (oversimplified, but you get the idea…):
>
> In a file Data.pm, which I would use() in my Apache startup.pl, I would
> load the perl hashes and have hash references that would be retrieved with
> class methods:
>
> package Data;
>
> my %big_hash;
>
> open(FILE,"file.txt");
>
> while (  ) {
>
>   … code ….
>
>   $big_hash{ $key } = $value;
> }
>
> sub get_big_hashref {   return \%big_hash; }
>
> 
>
> And so in the apache request handler, the code would be something like:
>
> use Data.pm;
>
> my $hashref = Data::get_big_hashref();
>
> …. code to access $hashref data with request parameters…..
>
> 
>
> The idea is the HTTP request/response will contain the relevant
> input/output for each case… and the master client program will collect
> these and concatentate the final output from all the requests.
>
> So any issues/suggestions with this approach? I am facing a non-trivial
> task of refactoring the existing code to work in this framework, so just
> wanted to get some feedback before I invest more time into this...
>
> I am planning on using mod_perl 2.07 on a linux machine.
>
> Thanks in advance, Alan
>

Re: mod_perl installed via yum but not used by application (RedHat 6.5 Apache 2.2.15 mod_perl 2.0.4)

[André Warnier]

BOUX Frederik wrote:

Hello,

I am using OTRS on a RedHat 6.5 with apache2 and mod_perl2. We are using these 
packages (yum info feedback):

Installed Packages
Name: httpd
Arch: x86_64
Version : 2.2.15
Release : 39.el6

Name: mod_perl
Arch: x86_64
Version : 2.0.4
Release : 11.el6_5

We noticed a performance difference with the Development server. I can see in 
htop that the apache user is spawning /usr/bin/perl processes to run all the 
perl scripts instead of handling them in an httpd process. So I placed the 
following script in the same directory as my index.pl to see if mod_perl was 
being used:

#!/usr/bin/perl
print "Content-type: text/plain\n\n";
print "Server's environment\n";
foreach ( keys %ENV ) {
print "$_\t$ENV{$_}\n";
}

Dev shows these two variables that are completely missing on Sandbox:

MOD_PERL_API_VERSION 2
MOD_PERL mod_perl/2.0.4

So I'm pretty sure mod_perl isn't being used . But as far as I can tell 
everything is configured:

1) /etc/httpd/conf.d/perl.conf contains the line: LoadModule perl_module 
modules/mod_perl.so

2) /etc/httpd/conf/httpd.conf contains an Include: Include conf.d/*.conf

3) this is the default .conf from OTRS but I can't find a mistake:

# Setup environment and preload modules
Perlrequire /opt/otrs/scripts/apache2-perl-startup.pl

# Reload Perl modules when changed on disk
PerlModule Apache2::Reload
PerlInitHandler Apache2::Reload

# general mod_perl2 options

#ErrorDocument 403 /otrs/customer.pl
ErrorDocument 403 /otrs/index.pl
SetHandler  perl-script
PerlResponseHandler ModPerl::Registry
Options +ExecCGI
PerlOptions +ParseHeaders
PerlOptions +SetupEnv



   Order allow,deny
   Allow from all

= 2.4>
Require all granted



Order allow,deny
Allow from all



# mod_perl2 options for GenericInterface

PerlOptions -ParseHeaders






And yet the module is loaded:

[user@server httpd]$ httpd -M | grep perl
Syntax OK
perl_module (shared)
[user@server httpd]$ httpd -l
Compiled in modules:
core.c
prefork.c
http_core.c
mod_so.c


Anyone who can spot a mistake or who has additional steps to troubleshoot why 
mod_perl isn't being used?



Just a little comment : when you restart your server, the first line in the error log 
should clearly show if mod_perl is included or not.


Also, if it isn't, then all the mod_perl specific configuration lines above should trigger 
an Apache error when it starts (and it would not start).

Errors such as
"PerlOptions" : unknown directive at line xxx ...

Unless your server actually starts with another configuration file set than the one you 
think..

Re: mod_perl for Apache 2.4

[Jie Gao]

I guess one way many of us can help is to test it in our own environment.

Authentication/authorisation would be the hard bit to get old code work 
with the new version.


Regards,

Jie 

* Randolf Richardson  wrote:

> Date: Tue, 13 Jan 2015 13:25:06 -0800
> From: Randolf Richardson 
> To: mod_perl list 
> CC: Randolf Richardson 
> Subject: Re: mod_perl for Apache 2.4
> X-mailer: Pegasus Mail for Windows (4.70)
> 
> > We hope to make a release (2.0.9) very soon. Apologies for the delay
> > in its arrival.
> 
>   This is fantastic news!  Thank you for all the hard work that you 
> and everyone has been putting into mod_perl2.  I've been looking 
> forward to this for quite some time, and I appreciate that there is a 
> lot of careful work that goes into these types of high quality 
> projects to ensure that they are reliable.
> 
>   (I've been using mod_perl2 on NetBSD with APRLIB, Apache HTTPd v2.2, 
> and PostgreSQL for as long as I can remember, and moving up to Apache 
> HTTPd v2.4 will be very helpful to me because there new newer HTTPd 
> has some features a few of the projects I'm working on will need 
> later this year, so the timing of this new release is excellent.)
> 
> [End of reply.]
> 
> > Until then you can fetch the latest source, which is likely very close
> > to what will become 2.0.9, from SVN:
> > https://svn.apache.org/repos/asf/perl/modperl/trunk/
> > 
> > On 13 January 2015 at 17:52, Hong Ye  wrote:
> > > Hi,
> > >
> > > Does anyone know when mod_perl for Apache 2.4 will be available for 
> > > download? Where can I download the mod_perl source code that  supports 
> > > Apache 2.4?
> > >
> > > Thanks,
> > > Hong
> > >
> 
> 
> Randolf Richardson - rand...@inter-corporate.com
> Inter-Corporate Computer & Network Services, Inc.
> Beautiful British Columbia, Canada
> http://www.inter-corporate.com/
> 
> 

Re: mod_perl for Apache 2.4

[Randolf Richardson]

> We hope to make a release (2.0.9) very soon. Apologies for the delay
> in its arrival.

This is fantastic news!  Thank you for all the hard work that you 
and everyone has been putting into mod_perl2.  I've been looking 
forward to this for quite some time, and I appreciate that there is a 
lot of careful work that goes into these types of high quality 
projects to ensure that they are reliable.

(I've been using mod_perl2 on NetBSD with APRLIB, Apache HTTPd v2.2, 
and PostgreSQL for as long as I can remember, and moving up to Apache 
HTTPd v2.4 will be very helpful to me because there new newer HTTPd 
has some features a few of the projects I'm working on will need 
later this year, so the timing of this new release is excellent.)

[End of reply.]

> Until then you can fetch the latest source, which is likely very close
> to what will become 2.0.9, from SVN:
> https://svn.apache.org/repos/asf/perl/modperl/trunk/
> 
> On 13 January 2015 at 17:52, Hong Ye  wrote:
> > Hi,
> >
> > Does anyone know when mod_perl for Apache 2.4 will be available for 
> > download? Where can I download the mod_perl source code that  supports 
> > Apache 2.4?
> >
> > Thanks,
> > Hong
> >


Randolf Richardson - rand...@inter-corporate.com
Inter-Corporate Computer & Network Services, Inc.
Beautiful British Columbia, Canada
http://www.inter-corporate.com/

Re: mod_perl for Apache 2.4

[Lathan Bidwell]

On Tue, Jan 13, 2015 at 1:02 PM, Steve Hay 
wrote:

> We hope to make a release (2.0.9) very soon. Apologies for the delay
> in its arrival.
>
>
Great News!

Will there be some updated doc pages with that release?

I know I'm having troubles with authentication combined with
DirectoryIndex, and the less documentation has affected that.



> Until then you can fetch the latest source, which is likely very close
> to what will become 2.0.9, from SVN:
> https://svn.apache.org/repos/asf/perl/modperl/trunk/
>
> On 13 January 2015 at 17:52, Hong Ye  wrote:
> > Hi,
> >
> > Does anyone know when mod_perl for Apache 2.4 will be available for
> download? Where can I download the mod_perl source code that  supports
> Apache 2.4?
> >
> > Thanks,
> > Hong
> >
>


Keep up the good work

Re: mod_perl for Apache 2.4

[Steve Hay]

We hope to make a release (2.0.9) very soon. Apologies for the delay
in its arrival.

Until then you can fetch the latest source, which is likely very close
to what will become 2.0.9, from SVN:
https://svn.apache.org/repos/asf/perl/modperl/trunk/

On 13 January 2015 at 17:52, Hong Ye  wrote:
> Hi,
>
> Does anyone know when mod_perl for Apache 2.4 will be available for download? 
> Where can I download the mod_perl source code that  supports Apache 2.4?
>
> Thanks,
> Hong
>

Re: mod_perl for Apache 2.4

[Hong Ye]

Hi,

Does anyone know when mod_perl for Apache 2.4 will be available for download? 
Where can I download the mod_perl source code that  supports Apache 2.4?

Thanks,
Hong

Re: mod_perl and utf8 and CGI->param

[Joe Schaefer]

apreq validates anything it presents as utf8, otherwise it marks it as ISO88591 
or some windows encoding I don't remember the name of if that fails.



On Monday, September 8, 2014 3:17 PM, André Warnier  wrote:
 


Michael Schout wrote:

> On 9/2/14, 4:19 PM, Randal L. Schwartz wrote:
> 
>>   ## ensure utf8 CGI params:
>>   $CGI::PARAM_UTF8 = 1;
> 
> Sorry to chime in late on this, but part of the problem with CGI.pm and
> UTF-8 is that PARAM_UTF8 gets clobbered by a cleanup handler that CGI.pm
> itself registers if its running under mod_perl.
> 
> This caused major headaches for me at one time until I figured this out.
> 
> You have to make sure to set $CGI::PARAM_UTF8 early, and FOR EVERY
> REQUEST, because if you just set it globally (e.g.: in a startup perl
> script), then it only works for the first request.
> 

Hi.
Just an addendum to the discussion :

There are really two distinct approaches to this issue, and they work at 
different levels :

1) is to "fix" CGI.pm so that it delivers the parameters in the way which you 
expect.
As shown by the previous valuable and technical contributions, this generally 
works, but 
it requires a certain level of expertise; and it does not necessarily work 
backwards with 
all versions of mod_perl and CGI.pm.

2) is to take whatever CGI.pm does deliver to the calling script or module, and 
use a 
couple of tricks and some additional code in ditto script or module, to ensure 
that 
whatever CGI.pm delivers under whatever mod_perl version, the receiving script 
or module 
always knows in the end what it is dealing with.
That is the method which I presented early in the discussion.
As stated in that contribution, it is not necessarily the most elegant or 
efficient way to 
deal with the issue, but it has the advantage of working always, no matter 
which version 
of CGI.pm and/or mod_perl are in use.

The real crux of the matter is this, in my view : as things stand today in 
terms of 
protocol and RFCs, there is no real way for CGI.pm (or any comparable 
framework) to be 
*sure* of the encoding of the data sent by a browser or another HTTP client 
agent.  Even 
the RFCs do not really provide a way by which this can be enforced. (*)

So if you are sure of what the client is sending, and the matter consists of 
*forcing* 
CGI.pm to always communicate POST (or GET) data as UTF-8 encoded and 
utf8-marked (or the 
opposite) to the calling script/module, then method 1 will work, and it is more 
elegant 
and probably more efficient than method 2.

But if the matter consists of ensuring that the receiving code in the 
script/module which 
  handles the data submitted by the HTTP client, is resilient and "does the 
right thing" 
whatever the submitted data really was, then in my opinion method 2 is better.
(But that's only my opinion of the moment, and I stand ready to be corrected).

(*) and if you believe this not to be true, please send me some references 
about it, 
because I am really interested. It might save me some code in all my web-facing 
applications.

Re: mod_perl and utf8 and CGI->param

[André Warnier]

Michael Schout wrote:

On 9/2/14, 4:19 PM, Randal L. Schwartz wrote:


  ## ensure utf8 CGI params:
  $CGI::PARAM_UTF8 = 1;


Sorry to chime in late on this, but part of the problem with CGI.pm and
UTF-8 is that PARAM_UTF8 gets clobbered by a cleanup handler that CGI.pm
itself registers if its running under mod_perl.

This caused major headaches for me at one time until I figured this out.

You have to make sure to set $CGI::PARAM_UTF8 early, and FOR EVERY
REQUEST, because if you just set it globally (e.g.: in a startup perl
script), then it only works for the first request.



Hi.
Just an addendum to the discussion :

There are really two distinct approaches to this issue, and they work at 
different levels :

1) is to "fix" CGI.pm so that it delivers the parameters in the way which you 
expect.
As shown by the previous valuable and technical contributions, this generally works, but 
it requires a certain level of expertise; and it does not necessarily work backwards with 
all versions of mod_perl and CGI.pm.


2) is to take whatever CGI.pm does deliver to the calling script or module, and use a 
couple of tricks and some additional code in ditto script or module, to ensure that 
whatever CGI.pm delivers under whatever mod_perl version, the receiving script or module 
always knows in the end what it is dealing with.

That is the method which I presented early in the discussion.
As stated in that contribution, it is not necessarily the most elegant or efficient way to 
deal with the issue, but it has the advantage of working always, no matter which version 
of CGI.pm and/or mod_perl are in use.


The real crux of the matter is this, in my view : as things stand today in terms of 
protocol and RFCs, there is no real way for CGI.pm (or any comparable framework) to be 
*sure* of the encoding of the data sent by a browser or another HTTP client agent.  Even 
the RFCs do not really provide a way by which this can be enforced. (*)


So if you are sure of what the client is sending, and the matter consists of *forcing* 
CGI.pm to always communicate POST (or GET) data as UTF-8 encoded and utf8-marked (or the 
opposite) to the calling script/module, then method 1 will work, and it is more elegant 
and probably more efficient than method 2.


But if the matter consists of ensuring that the receiving code in the script/module which 
 handles the data submitted by the HTTP client, is resilient and "does the right thing" 
whatever the submitted data really was, then in my opinion method 2 is better.

(But that's only my opinion of the moment, and I stand ready to be corrected).

(*) and if you believe this not to be true, please send me some references about it, 
because I am really interested. It might save me some code in all my web-facing applications.

Re: mod_perl and utf8 and CGI->param

[Michael Schout]

On 9/2/14, 4:19 PM, Randal L. Schwartz wrote:

>   ## ensure utf8 CGI params:
>   $CGI::PARAM_UTF8 = 1;

Sorry to chime in late on this, but part of the problem with CGI.pm and
UTF-8 is that PARAM_UTF8 gets clobbered by a cleanup handler that CGI.pm
itself registers if its running under mod_perl.

This caused major headaches for me at one time until I figured this out.

You have to make sure to set $CGI::PARAM_UTF8 early, and FOR EVERY
REQUEST, because if you just set it globally (e.g.: in a startup perl
script), then it only works for the first request.

Regards,
Michael Schout

Re: mod_perl and utf8 and CGI->param

[Randal L. Schwartz]

> "Randal" == Randal L Schwartz  writes:

Randal> Yeah, just coded that.  In a BEGIN block in my app, I monkey-patched
Randal> read_from_client:

And then I've also tried to monkey-patch ->read just as you said.

On the first read, an empty string is apparently returned, which fails
something higher in CGI.pm.  Ugh.

Update:

This monkey patch works:

  *Apache2::RequestRec::read = sub {
warn "READ CALLED";
goto &$orig;
  }

Although it doesn't do any decoding.  When I replace the body of that
with your code, I'm getting these zero-byte reads.  Even this fails:

my ($r, $buff, $len, $offset)=@_;
# my $_buff;
# my $rc = $r->$orig($_buff, $len);
my $rc = $r->$orig($buff, $len, $offset);
# warn "BEFORE: ", DBI::data_string_desc($_buff);
# utf8::decode($_buff);
# warn "AFTER: ", DBI::data_string_desc($_buff);
# substr($buff, $offset, undef, $_buff);
# warn "AFTER: ", DBI::data_string_desc($buff);
return $rc;

which should be the same as your code without the utf8 encoding still.
Still getting 0 bytes though.

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
 http://www.stonehenge.com/merlyn/>
Perl/Unix consulting, Technical writing, Comedy, etc. etc.
Still trying to think of something clever for the fourth line of this .sig

Re: mod_perl and utf8 and CGI->param

[Randal L. Schwartz]

> "Torsten" == Torsten Förtsch  writes:

Torsten> Though, I wouldn't go this way. I'd either try to force CGI.pm to read
Torsten> from STDIN and use the perl-script handler
Torsten> 
(http://perl.apache.org/docs/2.0/user/config/config.html#C_perl_script_). This
Torsten> pushes a PerlIO layer to STDIN so that you can read from STDIN. On top
Torsten> of that you can push :utf8 then.

Yeah, just coded that.  In a BEGIN block in my app, I monkey-patched
read_from_client:

BEGIN {
  ## monkey-patch CGI.pm so we can get proper utf8 handling
  require CGI;
  CGI::_compile_all(qw(
read_from_client
 ));
  # warn "defined &CGI::read_from_client is ", 0 + defined
  &CGI::read_from_client;

  ## moose 'around' would be nice here. :)
  my $read_from_client = \&CGI::read_from_client;
  no warnings 'redefine';
  *CGI::read_from_client = sub {
local $CGI::MOD_PERL = $CGI::MOD_PERL;
warn "prior MOD_PERL is $CGI::MOD_PERL";
if (our $USE_STDIN_FOR_MOD_PERL) {
  $CGI::MOD_PERL = 0;
}
warn "after MOD_PERL is $CGI::MOD_PERL";
goto &$read_from_client;
  }
}

And in my toplevel, I now do this:

sub activate {
  my $self = shift;

  require Carp;
  local $SIG{__DIE__} = \&Carp::confess;

  ## ensure utf8 CGI params:
  local $CGI::PARAM_UTF8 = 1;
  ## and disable mod_perl handling during read_from_client
  local our $USE_STDIN_FOR_MOD_PERL = 1;

  binmode STDIN, ":utf8";
  binmode STDOUT, ":utf8";
  binmode STDERR, ":utf8";

  return $self->SUPER::activate(@_);
}

(This is my CGI::Prototype-based code, from the CPAN...)

I'm properly getting the $CGI::MOD_PERL set to 0, which forces
read from STDIN (via $r) instead of the native STDIN.  In theory.  In
practice, even though I've done a binmode STDIN, I'm still getting raw
bytes from read(\*STDIN...), not utf8-tagged strings.

Not sure what to do next.  Still frustrated.

Why can't the world just use ASCII? :)

(I even tried binmode STDIN, "encoding(utf8)" just now as well.)

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
 http://www.stonehenge.com/merlyn/>
Perl/Unix consulting, Technical writing, Comedy, etc. etc.
Still trying to think of something clever for the fourth line of this .sig

Re: mod_perl and utf8 and CGI->param

[Torsten Förtsch]

On 03/09/14 21:38, Randal L. Schwartz wrote:
> What I need to know is what is mod_perl doing differently?  Does it not
> respect binmode STDIN, ":utf8"?  Apparently not.  So if you know of a
> way to get mod_perl to "fix" reading from the browser properly, I'm
> interested in that.

Something along these lines:

use Apache2::RequestIO ();
use Encode ();
BEGIN {
my $orig=\&Apache2::RequestRec::read;
*Apache2::RequestRec::read=sub {
my ($r, $buf, $len, $offset)=@_;
my $_buf;
my $rc=$r->$orig($_buf, $len);
substr($buf, $offset, undef, Encode::decode_utf8 $_buf);
return $rc;
};
}

It's a bit more complicated than that because $_buf may end in the
middle of a character. But you can catch that and read a few more bytes.
Also, not sure if you expect the return value to be in octets or characters.

Though, I wouldn't go this way. I'd either try to force CGI.pm to read
from STDIN and use the perl-script handler
(http://perl.apache.org/docs/2.0/user/config/config.html#C_perl_script_). This
pushes a PerlIO layer to STDIN so that you can read from STDIN. On top
of that you can push :utf8 then.

The other way I'd prefer over the hack above is to patch CGI.pm to
convert the data after it has read it. You can even do that in your
application. Many applications I have seen have a separate step to
sanitize the input. That would be the place to do that. However, then
you have to watch out for upload fields.

So, there is no really simple solution. And I don't think this will be
"fixed" in modperl because $r has no such concept as an IO layer. The
closest thing httpd/modperl has to offer is an input filter. But that
won't help you here because brigades are handled mainly by httpd which
knows only about octets. You don't want to change the data itself. You
want to change the data's metadata.

Torsten

Re: mod_perl and utf8 and CGI->param

[Dr James A Smith]

I encode a "pound sign" which as a parameter which indicates whether 
content is UTF-8, UCS or latin-1 - and this seems to resolve most of the 
issues... I did take a lot of effort to fix issues with utf8 and there 
are a lot of these - between form -> post; between requests if storing 
data in sessions; between script and database; etc...


I do however not use CGI.pm  but use APR instead which I know works (and 
may be less error prone)


James

---
This email is free from viruses and malware because avast! Antivirus protection 
is active.
http://www.avast.com



--
The Wellcome Trust Sanger Institute is operated by Genome Research 
Limited, a charity registered in England with number 1021457 and a 
company registered in England with number 2742969, whose registered 
office is 215 Euston Road, London, NW1 2BE. 

Re: mod_perl and utf8 and CGI->param

[Randal L. Schwartz]

> "André" == André Warnier  writes:


André> The methodology I follow is as follows :

André> 1) all html  pages of the applications should have a tag like :
André> 
André> 2) all  in the page should have the attributes
André> enctype="application/form-data"
André> accept-charset="." (the same as above)

I've pretty much got success with CGI (and CGI.pm) doing the things I
listed above.  So this isn't needed.  I'm not having problems with the
browser, Apache, or Perl, or RDBO, or Postgresql.  (Even that took a bit
of work to get working, and so I think none of those are the issue.)

What I need to know is what is mod_perl doing differently?  Does it not
respect binmode STDIN, ":utf8"?  Apparently not.  So if you know of a
way to get mod_perl to "fix" reading from the browser properly, I'm
interested in that.

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
 http://www.stonehenge.com/merlyn/>
Perl/Unix consulting, Technical writing, Comedy, etc. etc.
Still trying to think of something clever for the fourth line of this .sig

Re: mod_perl and utf8 and CGI->param

[Cosimo Streppone]

On 09/03/2014 11:17 AM, André Warnier wrote:

> 3) all forms contain a hidden text  like
>   (some known
> sequence of "diacritics" characters guaranteed to have a different byte
> length between ISO-8859-x and UTF-8 encoding)
> [...]
> But it's helped me sleep better for quite a while now.

This is brilliant :-)
Thanks André.

-- 
Cosimo

Re: mod_perl and utf8 and CGI->param

[André Warnier]

Hi Randal.

Randal L. Schwartz wrote:

Getting really frustrated with mod_perl2's apparent inability to
probably read UTF8 input.

Here's my mod_perl2 setup:

  Apache 2.2.[something]
  mod_perl 2.0.7 (or nearly that)
  ModPerl::Registry
  Perl "script" with CGI.pm

Very early in my app:

  ## ensure utf8 CGI params:
  $CGI::PARAM_UTF8 = 1;

  binmode STDIN, ":utf8";
  binmode STDOUT, ":utf8";
  binmode STDERR, ":utf8";

This works fine in CGI mode: when I ask for $foo = $cgi->param('foo'),
DBI::data_string_desc($foo) shows a UTF8 string with the proper
discrepency between bytes and chars.

But when I try to run it under mod_perl, the returned string appears
to be the raw ascii bytes, and definitely not utf8.  Of course, when I
store that in the database (using DBD::Pg), the "latin-1" is encoded
to "utf-8", and I get a bunch of weird chars on the output.

Has anyone managed to round-trip UTF8 from form to database and back
using a setup similar to this?

I suspect part of the problem is this in CGI.pm:

'read_from_client' => <<'END_OF_FUNC',
# Read data from a file handle
sub read_from_client {
my($self, $buff, $len, $offset) = @_;
local $^W=0;# prevent a warning
return $MOD_PERL
? $self->r->read($$buff, $len, $offset)
: read(\*STDIN, $$buff, $len, $offset);
}
END_OF_FUNC

Since I binmode STDIN, the non-$MOD_PERL works ok here.  What's the
equivalent of $r->read() that marks the incoming stream as UTF8, so I
get chars instead of bytes?  Or can I just read(\*STDIN) in mod_perl2
as well? (I know that was supported at one point...)





I share your frustration, as I have been dealing for a long time with multi-lingual web 
applications, using perl and mod_perl.


First a very top-level comment : the basic problem here is the incompleteness of the HTTP 
RFC's, and the lack of proper support of international characters sets, even still today.
When a browser is POST-ing the contents of the  elements of a  to a server, 
there is a set of arcane rules which, in principle, determine the character set in which 
this content is encoded.  The problem is that these arcane rules are arcane, often 
confusing, and in addition regularly flouted by different browser makes and versions (not 
to even talk about umpteen non-browser proprietary HTTP client things).


For example, when a browser sends the content of a form in the "application/form-data" 
"enctype", the content of each form parameter is sent as a separate section, in a form 
similar to the parts in a multi-part RFC-822 email.  In theory, each of these parts should 
have its own "content-type" header, and if it is text, it should also contain a "charset" 
attribute indicating the corresponding data's encoding.
(and if it doesn't, by virtue of the HTTP RFC's, it should be ISO-8859-1, which is still 
the default HTTP character today; quite ridiculous, but so it is).


But the sad reality is that browser don't do that, and so in the practice in many cases 
the server-side application is reduced to "guessing".


By experience more than by definite code knowledge, I have to suppose that this kind of 
confusion sometimes also hits developers of modules such a CGI.pm and mod_perl, so that 
over the years, things have tended to vary from one version to another (versions of 
browsers, versions of perl, versions of mod_perl, versions of CGI.pm).  Maybe also because 
of all the reasons above, there is just no "right" way of handling this, so CGI.pm always 
returns "bytes" (and libapreq2 may do things differwently).


In the end, rather than trying to follow the latest developments all the time and 
continuously patch my programs because of all this, I have resorted to some "defensive 
programming" techniques in terms of interpreting -posted data, which have been 
working fine for me for the last few years.  It may well be that they are a total 
overkill, but in the practice they have saved me a lot of time not spent wondering why the 
data in some application suddenly started to show up as "A tilde" followed by some bizarre 
graphic sign (or, at the opposite, as a question mark embedded in a losange).


(Even logging this stuff and trying to figure out what is going on is a pain, because you 
have to figure out first in what encoding you are logging, and second in what encoding you 
are viewing your logs).


The methodology I follow is as follows :

1) all html  pages of the applications should have a tag like :

2) all  in the page should have the attributes
enctype="application/form-data"
accept-charset="." (the same as above)

The above 2 things do not really guarantee anything, but at least they establish some 
"baseline" which helps in interpreting the rest (and slapping users when they change their 
browser settings).


3) all forms contain a hidden text  like
  (some known sequence of 
"diacritics" characters guaranteed to have a different byte length between ISO-8859-x and 
UTF-8 encoding)


Th

Re: mod_perl 2.0.8 for Apache 3.4 on Windows

[Lars Dɪᴇᴄᴋᴏᴡ 迪拉斯]

> I have found ExtUtils::Embed 1.3001 at
>   C:/Perl64/lib/ExtUtils/Embed.pm
Which Perl distribution is that? Which steps did you take to get that
error message?

You need to find out how you ended up with a version that is not in a
release of Perl:


The usual answer, namely through an upgrade from CPAN, does not apply -
E::E's dual-life counterpart was last released in 1997.


signature.asc
Description: PGP signature

Re: mod_perl and Transfer-Encoding: chunked

[Torsten Förtsch]

On 04/07/13 17:48, Bill Moseley wrote:
> Applications probably don't
> need to care.  They should receive the body -- so for mod_perl that means
> reading data using $r->read until there's no more to read and then the app
> should never need to look at the Transfer-Encoding header -- or
> Content-Length header for that matter by that reasoning.

Modperl simply makes (most of) the httpd interface available to perl. I
see no reason to remove the TE header in modperl. If httpd decides to do
that, so be it. Modperl must not.

$r->read is simply a convenience layer on top of bucket brigades. If you
don't like $r->read, fetch the buckets from the input filter chain.

But I see, the documentation of $r->read could be improved.

Note, it's also safer to use bucket brigades directly unless you know
your input filters quite well. Have a look at the XXX comment in
modperl_request_read in modperl_io_apache.c. Normally, httpd tries to
reads its input in 8k chunks. So, providing a buffer of 10k to $r->read
should be enough. Though, you don't have to provide the actual space.
$r->read expands the provided buffer as necessary. Only make sure not to
pass a length parameter that is too small.

Actually, I think we should either ignore the length parameter and pass
the flattened brigade to the caller or we should introduce some kind of
buffering to remove that XXX bug.

I'd prefer the former.

Opinions?

Torsten

Re: mod_perl and Transfer-Encoding: chunked

[André Warnier]

Bill Moseley wrote:

André, thanks for the response:

On Thu, Jul 4, 2013 at 4:06 AM, André Warnier  wrote:


Bill Moseley wrote:


First, if $r->read reads unchunked data then why is there a
Transfer-Encoding header saying that the content is chunked?   Shouldn't
that header be removed?


Looking at the RFC again the answer appears to be yes.   Look at the last
line in this decoding example in
http://tools.ietf.org/html/rfc2616#section-19.4.6

   A process for decoding the "chunked" transfer-coding (section 3.6
)
   can be represented in pseudo-code as:

   length := 0
   read chunk-size, chunk-extension (if any) and CRLF
   while (chunk-size > 0) {
  read chunk-data and CRLF
  append chunk-data to entity-body
  length := length + chunk-size
  read chunk-size and CRLF
   }
   read entity-header
   while (entity-header not empty) {
  append entity-header to existing header fields
  read entity-header
   }
   Content-Length := length
   Remove "chunked" from Transfer-Encoding


Apache/mod_perl is doing the first part but not updating the headers.

There's more on Content-Length and Transfer-Encoding here:
http://tools.ietf.org/html/rfc2616#section-4.4



   How does one know if the content is chunked or not, otherwise?

The real question is : does one need to know ?



Perhaps.  That's an interesting question.   Applications probably don't
need to care.  They should receive the body -- so for mod_perl that means
reading data using $r->read until there's no more to read and then the app
should never need to look at the Transfer-Encoding header -- or
Content-Length header for that matter by that reasoning.

It's a bit less clear if you think about Plack.  It sits between web
servers and applications.   What should, say, a Plack Middleware component
see in the body if the headers say Trasnfer-Encoding: chunked?   The
decoding probably should happen in the
server,
but the headers would need to indicate that by removing the
Transfer-Encoding header and adding in the Content-Length.



Perhaps I'm approaching this incorrectly, but this is all a bit untidy.

I'm using Catalyst and Catalyst needs a Content-Length.


I would posit then that Catalyst is wrong (or not compatible with HTTP 1.1
in that respect).



But, Catalyst is a web application (framework) and from your point above it
should not care about the encoding and just read the input stream by
calling ->read().   Really, if you think about Plack, Catalyst should never
make exceptions based on $ENV{MOD_PERL}.

So, the separation of concerns between the web server and the app is not
very clean.




  So, I have a Plack


Middleware component that creates a temporary file writing the buffer from
$r->read( my $buffer, 64 * 1024 ) until that returns zero bytes.  I pass
this file handle onto Catalyst.



So what you wrote then is a patch to Catalyst.



No, the Middleware component should be usable for any application.   And
likewise, for any web server.  That's the point of Plack.

Obviously, there's differences between web servers and maybe we need code
that understans when running under mod_perl that the Transfer-Encoding:
chunked header should be ignored, but if that code must live in Catalyst
then that's really breaking the separation that Plack provides.

I think the sane thing here is if Apache/mod_perl didn't provide a header
saying the body is chunked, when it isn't.   Otherwise, code (Plack, web
apps) that receive a set of headers and a handle to read from don't really
have any choice but to believe what it is told.





I can see your point, but to me it depends at which level this add-on code 
"lives".
I do not know Plack or Catalyst, and do not know at which level each of them is supposed 
to "live".
But to me, if the code lives at the "web-app" level, at that point it should just consider 
the request body as one piece or stream, without intervening "chunk headers".
(and it should treat the Content-transfer-encoding header as informational only, maybe to 
know that it should not expect a Content-length header, and that it can only know the body 
length by reading it).


It is different in the case of a mod_perl "connection filter".  That one really sees the 
stream of bytes coming from the browser, request line, headers, body chunked or not, etc..
(And it should see several requests pipelined on the same connection, one after the other, 
as one stream of bytes, without any particular break between them other that what it can 
figure out itself.)


But even a "request filter" (which comes before a web-app) should see the request body as 
already "de-chunked" (re-assembled).


See here for example : 
http://perl.apache.org/docs/2.0/user/handlers/filters.html#HTTP_Request_Versus_Connection_Filters


which I got to starting from here :
http://perl.apache.org

Re: mod_perl and Transfer-Encoding: chunked

[Bill Moseley]

André, thanks for the response:

On Thu, Jul 4, 2013 at 4:06 AM, André Warnier  wrote:

>
> Bill Moseley wrote:
>
>>
>> First, if $r->read reads unchunked data then why is there a
>> Transfer-Encoding header saying that the content is chunked?   Shouldn't
>> that header be removed?
>>
>
Looking at the RFC again the answer appears to be yes.   Look at the last
line in this decoding example in
http://tools.ietf.org/html/rfc2616#section-19.4.6

   A process for decoding the "chunked" transfer-coding (section 3.6
)
   can be represented in pseudo-code as:

   length := 0
   read chunk-size, chunk-extension (if any) and CRLF
   while (chunk-size > 0) {
  read chunk-data and CRLF
  append chunk-data to entity-body
  length := length + chunk-size
  read chunk-size and CRLF
   }
   read entity-header
   while (entity-header not empty) {
  append entity-header to existing header fields
  read entity-header
   }
   Content-Length := length
   Remove "chunked" from Transfer-Encoding


Apache/mod_perl is doing the first part but not updating the headers.

There's more on Content-Length and Transfer-Encoding here:
http://tools.ietf.org/html/rfc2616#section-4.4



   How does one know if the content is chunked or not, otherwise?
>>
>
> The real question is : does one need to know ?
>

Perhaps.  That's an interesting question.   Applications probably don't
need to care.  They should receive the body -- so for mod_perl that means
reading data using $r->read until there's no more to read and then the app
should never need to look at the Transfer-Encoding header -- or
Content-Length header for that matter by that reasoning.

It's a bit less clear if you think about Plack.  It sits between web
servers and applications.   What should, say, a Plack Middleware component
see in the body if the headers say Trasnfer-Encoding: chunked?   The
decoding probably should happen in the
server,
but the headers would need to indicate that by removing the
Transfer-Encoding header and adding in the Content-Length.


>> Perhaps I'm approaching this incorrectly, but this is all a bit untidy.
>>
>> I'm using Catalyst and Catalyst needs a Content-Length.
>>
>
> I would posit then that Catalyst is wrong (or not compatible with HTTP 1.1
> in that respect).


But, Catalyst is a web application (framework) and from your point above it
should not care about the encoding and just read the input stream by
calling ->read().   Really, if you think about Plack, Catalyst should never
make exceptions based on $ENV{MOD_PERL}.

So, the separation of concerns between the web server and the app is not
very clean.



>   So, I have a Plack
>
>> Middleware component that creates a temporary file writing the buffer from
>> $r->read( my $buffer, 64 * 1024 ) until that returns zero bytes.  I pass
>> this file handle onto Catalyst.
>>
>>
> So what you wrote then is a patch to Catalyst.
>

No, the Middleware component should be usable for any application.   And
likewise, for any web server.  That's the point of Plack.

Obviously, there's differences between web servers and maybe we need code
that understans when running under mod_perl that the Transfer-Encoding:
chunked header should be ignored, but if that code must live in Catalyst
then that's really breaking the separation that Plack provides.

I think the sane thing here is if Apache/mod_perl didn't provide a header
saying the body is chunked, when it isn't.   Otherwise, code (Plack, web
apps) that receive a set of headers and a handle to read from don't really
have any choice but to believe what it is told.



-- 
Bill Moseley
mose...@hank.org

Re: mod_perl and Transfer-Encoding: chunked

[André Warnier]

Not disregarding the other answers to your questions, but I believe that maybe one aspect 
has been neglected here.


Bill Moseley wrote:

For requests that are chunked (Transfer-Encoding: chunked and no
Content-Length header) calling $r->read returns *unchunked* data from the
socket.

That's indeed handy.  Is that mod_perl doing that un-chunking or is it
Apache?

But, it leads to some questions.

First, if $r->read reads unchunked data then why is there a
Transfer-Encoding header saying that the content is chunked?   Shouldn't
that header be removed?   How does one know if the content is chunked or
not, otherwise?


The real question is : does one need to know ?

The transfer-coding is something that even an intermediate HTTP proxy may
be allowed to change, for reasons to do with transport of the request along a section of 
the network path.

It should be entirely transparent to the application receiving the data.



Second, if there's no Content-Length header then how does one know how much
data to read using $r->read?

One answer is until $r->read returns zero bytes, of course.  


Indeed. That means that the end of *this* request body has been encountered.

But, is

that guaranteed to always be the case, even for, say, pipelined requests?


It should be, because $r concerns the present request being processed.
If there is another request pipelined onto that same connection, it is a separate request 
and a different $r.



My guess is yes because whatever is de-chunking the request knows to stop
after reading the last chunk, trailer and empty line.   Can
anyone elaborate on how Apache/mod_perl is doing this?



I can't really, but it should be done by something at some fairly low level.  It should be 
the *first* thing which happens to the request body, before any request-level body access 
is allowed.
(Similarly, at the response level, "chunking" a response body should be the last thing 
happening before the request is put on the wire out.)




Perhaps I'm approaching this incorrectly, but this is all a bit untidy.

I'm using Catalyst and Catalyst needs a Content-Length.


I would posit then that Catalyst is wrong (or not compatible with HTTP 1.1 in 
that respect).

  So, I have a Plack

Middleware component that creates a temporary file writing the buffer from
$r->read( my $buffer, 64 * 1024 ) until that returns zero bytes.  I pass
this file handle onto Catalyst.



So what you wrote then is a patch to Catalyst.


Then, for some content-types, Catalyst (via HTTP::Body) writes the body to *
another* temp file.I don't know how Apache/mod_perl does its
de-chunking, but I can call $r->read with a huge buffer length and Apache
returns that.  So, maybe Apache is buffering to disk, too.

In other words, for each tiny chunked JSON POST or PUT I'm creating two (or
three?) temp files which doesn't seem ideal.




I realise that my comments above don't really help you in your specific predicament, but I 
just felt that it was good to put things back in their place, particularly that at the $r 
(request) level, you should not have to know if the request came in chunked or not.
And that if a client sends a request with a chunked body, you are not necessarily gettting 
it so on the server on the which application runs.  And vice-versa.

Re: mod_perl and Transfer-Encoding: chunked

[Issac Goldstand]

On 03/07/2013 23:42, Joseph Schaefer wrote:
> Dechunked means it strips out the lines containing metadata about the next 
> block of raw data. The metadata is just the length of the next block of data. 
>  Imagine a chunked stream is like having partial content length headers 
> embedded in the data stream.
> 
> The http filter embedded in httpd takes care of the metadata so you don't 
> have to parse the stream yourself. $r->read will always provide only the raw 
> data in a blocking call, until the stream is finished in which case it should 
> return 0 or an error code.  Check the mod perl docs, or better the source, to 
> see if the semantics are more like perl's sysread or more like read.
> 

Yep.  That makes sense to me too - it's just not what I read in your
previous email, but maybe I read it wrong :)

> Sent from my iPhone
> 
> On Jul 3, 2013, at 4:31 PM, Jim Schueler  wrote:
> 
>> In light of Joe Schaefer's response, I appear to be outgunned.  So, if 
>> nothing else, can someone please clarify whether "de-chunked" means 
>> re-assembled?
>>
>> -Jim
>>
>> On Wed, 3 Jul 2013, Jim Schueler wrote:
>>
>>> Thanks for the prompt response, but this is your question, not mine.  I 
>>> hardly need an RTFM for my trouble.
>>>
>>> I drew my conclusions using a packet sniffer.  And as far-fetched as my 
>>> answer may seem, it's more plausible than your theory that Apache or 
>>> modperl is decoding a raw socket stream.
>>>
>>> The crux of your question seems to be how the request content gets
>>> magically re-assembled.  I don't think it was ever disassembled in the 
>>> first place.  But if you don't like my answer, and you don't want to ignore 
>>> it either, then please restate the question.  I can't find any definition 
>>> for unchunked, and Wiktionary's definition of de-chunk says to "break apart 
>>> a chunk", that is (counter-intuitively) chunk a chunk.
>>>
>>>
   Second, if there's no Content-Length header then how
   does one know how much
   data to read using $r->read?   

   One answer is until $r->read returns zero bytes, of
   course.  But, is
   that guaranteed to always be the case, even for,
   say, pipelined requests?  
   My guess is yes because whatever is de-chunking the
>>>
>>> read() is blocking.  So it never returns 0, even in a pipeline request (if 
>>> no data is available, it simply waits).  I don't wish to discuss the merits 
>>> here, but there is no technical imperative for a content-length request in 
>>> the request header.
>>>
>>> -Jim
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Wed, 3 Jul 2013, Bill Moseley wrote:
>>>
 Hi Jim,
 This is the Transfer-Encoding: chunked I was writing about:
 http://tools.ietf.org/html/rfc2616#section-3.6.1
 On Wed, Jul 3, 2013 at 11:34 AM, Jim Schueler 
 wrote:
 I played around with chunking recently in the context of media
 streaming: The client is only requesting a "chunk" of data.
  "Chunking" is how media players perform a "seek".  It was
 originally implemented for FTP transfers:  E.g, to transfer a
 large file in (say 10K) chunks.  In the case that you describe
 below, if no Content-Length is specified, that indicates "send
 the remainder".

> From what I know, a "chunk" request header is used this way to
 specify the server response.  It does not reflect anything about
 the data included in the body of the request.  So first, I would
 ask if you're confused about this request information.

 Hypothetically, some browsers might try to upload large files in
 small chunks and the "chunk" header might reflect a push
 transfer.  I don't know if "chunk" is ever used for this
 purpose.  But it would require the following characteristics:

   1.  The browser would need to originally inquire if the server
 is
   capable of this type of request.
   2.  Each chunk of data will arrive in a separate and
 independent HTTP
   request.  Not necessarily in the order they were sent.
   3.  Two or more requests may be handled by separate processes
   simultaneously that can't be written into a single
 destination.
   4.  Somehow the server needs to request a resend if a chunk is
 missing.
   Solving this problem requires an imaginitive use of HTTP.

 Sounds messy.  But might be appropriate for 100M+ sized uploads.
  This *may* reflect your situation.  Can you please confirm?

 For a single process, the incoming content-length is
 unnecessary. Buffered I/O automatically knows when transmission
 is complete.  The read() argument is the buffer size, not the
 content length.  Whether you spool the buffer to disk or simply
 enlarge the buffer should be determ

Re: mod_perl and Transfer-Encoding: chunked

[Issac Goldstand]

On 03/07/2013 23:26, Jim Schueler wrote:

> 
>> Second, if there's no Content-Length header then how
>> does one know how much
>> data to read using $r->read?   
>>
>> One answer is until $r->read returns zero bytes, of
>> course.  But, is
>> that guaranteed to always be the case, even for,
>> say, pipelined requests?  
>> My guess is yes because whatever is de-chunking the
> 
> read() is blocking.  So it never returns 0, even in a pipeline request
> (if no data is available, it simply waits).  I don't wish to discuss the
> merits here, but there is no technical imperative for a content-length
> request in the request header.
> 
>  -Jim

Probably.  If you, for some reason, were doing the chunking work
yourself, each chunk says how many bytes are in it (or in the next one
perhaps; I forget offhand), so you'd know what size read to do.

> 
> 
> 
> 
> 
> On Wed, 3 Jul 2013, Bill Moseley wrote:
> 
>> Hi Jim,
>> This is the Transfer-Encoding: chunked I was writing about:
>>
>> http://tools.ietf.org/html/rfc2616#section-3.6.1
>>
>>
>>
>> On Wed, Jul 3, 2013 at 11:34 AM, Jim Schueler 
>> wrote:
>>   I played around with chunking recently in the context of media
>>   streaming: The client is only requesting a "chunk" of data.
>>"Chunking" is how media players perform a "seek".  It was
>>   originally implemented for FTP transfers:  E.g, to transfer a
>>   large file in (say 10K) chunks.  In the case that you describe
>>   below, if no Content-Length is specified, that indicates "send
>>   the remainder".
>>
>>   >From what I know, a "chunk" request header is used this way to
>>   specify the server response.  It does not reflect anything about
>>   the data included in the body of the request.  So first, I would
>>   ask if you're confused about this request information.
>>
>>   Hypothetically, some browsers might try to upload large files in
>>   small chunks and the "chunk" header might reflect a push
>>   transfer.  I don't know if "chunk" is ever used for this
>>   purpose.  But it would require the following characteristics:
>>
>> 1.  The browser would need to originally inquire if the server
>>   is
>> capable of this type of request.
>> 2.  Each chunk of data will arrive in a separate and
>>   independent HTTP
>> request.  Not necessarily in the order they were sent.
>> 3.  Two or more requests may be handled by separate processes
>> simultaneously that can't be written into a single
>>   destination.
>> 4.  Somehow the server needs to request a resend if a chunk is
>>   missing.
>> Solving this problem requires an imaginitive use of HTTP.
>>
>>   Sounds messy.  But might be appropriate for 100M+ sized uploads.
>>This *may* reflect your situation.  Can you please confirm?
>>
>>   For a single process, the incoming content-length is
>>   unnecessary. Buffered I/O automatically knows when transmission
>>   is complete.  The read() argument is the buffer size, not the
>>   content length.  Whether you spool the buffer to disk or simply
>>   enlarge the buffer should be determined by your hardware
>>   capabilities.  This is standard IO behavior that has nothing to
>>   do with HTTP chunk.  Without a "Content-Length" header, after
>>   looping your read() operation, determine the length of the
>>   aggregate data and pass that to Catalyst.
>>
>>   But if you're confident that the complete request spans several
>>   smaller (chunked) HTTP requests, you'll need to address all the
>>   problems I've described above, plus the problem of re-assembling
>>   the whole thing for Catalyst.  I don't know anything about
>>   Plack, maybe it can perform all this required magic.
>>
>>   Otherwise, if the whole purpose of the Plack temporary file is
>>   to pass a file handle, you can pass a buffer as a file handle.
>>Used to be IO::String, but now that functionality is built into
>>   the core.
>>
>>   By your last paragraph, I'm really lost.  Since you're already
>>   passing the request as a file handle, I'm guessing that Catalyst
>>   creates the tempororary file for the *response* body.  Can you
>>   please clarify?  Also, what do you mean by "de-chunking"?  Is
> >   that the same think as re-assembling?
>>
>>   Wish I could give a better answer.  Let me know if this helps.
>>
>>   -Jim
>>
>>
>>   On Tue, 2 Jul 2013, Bill Moseley wrote:
>>
>> For requests that are chunked (Transfer-Encoding:
>> chunked and no
>> Content-Length header) calling $r->read returns
>> unchunked data from the
>> socket.
>> That's indeed handy.  Is that mod_perl doing that
>> un-chunking o

Re: mod_perl and Transfer-Encoding: chunked

[Issac Goldstand]

On 03/07/2013 21:53, Joseph Schaefer wrote:
> When you read from the input filter chain as $r->read does, the http
> input filter automatically handles the protocol and passes the dechunked
> data up to the caller. It does not spool the stream at all.
> 
> You'd have to look at how mod perl implements read to see if it loops
> its ap_get_brigade calls on the input filter chain to fill the passed
> buffer to the desired length or not.  But under no circumstances should
> you have to deal with chunked data directly.

I'm pretty sure that it's not even a mod_perl thing.  IIRC, httpd itself
sticks a chunk/de-chunk filter near the respective ends of the filter
chain.  So if you can't find the code in mod_perl land, you might want
to check httpd source.

> 
> HTH
> 
> Sent from my iPhone
> 
> On Jul 3, 2013, at 2:44 PM, Bill Moseley  > wrote:
> 
>> Hi Jim,
>>
>> This is the Transfer-Encoding: chunked I was writing about:
>>
>> http://tools.ietf.org/html/rfc2616#section-3.6.1
>>
>>
>>
>> On Wed, Jul 3, 2013 at 11:34 AM, Jim Schueler > > wrote:
>>
>> I played around with chunking recently in the context of media
>> streaming: The client is only requesting a "chunk" of data.
>>  "Chunking" is how media players perform a "seek".  It was
>> originally implemented for FTP transfers:  E.g, to transfer a
>> large file in (say 10K) chunks.  In the case that you describe
>> below, if no Content-Length is specified, that indicates "send the
>> remainder".
>>
>> From what I know, a "chunk" request header is used this way to
>> specify the server response.  It does not reflect anything about
>> the data included in the body of the request.  So first, I would
>> ask if you're confused about this request information.
>>
>> Hypothetically, some browsers might try to upload large files in
>> small chunks and the "chunk" header might reflect a push transfer.
>>  I don't know if "chunk" is ever used for this purpose.  But it
>> would require the following characteristics:
>>
>>   1.  The browser would need to originally inquire if the server is
>>   capable of this type of request.
>>   2.  Each chunk of data will arrive in a separate and independent
>> HTTP
>>   request.  Not necessarily in the order they were sent.
>>   3.  Two or more requests may be handled by separate processes
>>   simultaneously that can't be written into a single destination.
>>   4.  Somehow the server needs to request a resend if a chunk is
>> missing.
>>   Solving this problem requires an imaginitive use of HTTP.
>>
>> Sounds messy.  But might be appropriate for 100M+ sized uploads.
>>  This *may* reflect your situation.  Can you please confirm?
>>
>> For a single process, the incoming content-length is unnecessary.
>> Buffered I/O automatically knows when transmission is complete.
>>  The read() argument is the buffer size, not the content length.
>>  Whether you spool the buffer to disk or simply enlarge the buffer
>> should be determined by your hardware capabilities.  This is
>> standard IO behavior that has nothing to do with HTTP chunk.
>>  Without a "Content-Length" header, after looping your read()
>> operation, determine the length of the aggregate data and pass
>> that to Catalyst.
>>
>> But if you're confident that the complete request spans several
>> smaller (chunked) HTTP requests, you'll need to address all the
>> problems I've described above, plus the problem of re-assembling
>> the whole thing for Catalyst.  I don't know anything about Plack,
>> maybe it can perform all this required magic.
>>
>> Otherwise, if the whole purpose of the Plack temporary file is to
>> pass a file handle, you can pass a buffer as a file handle.  Used
>> to be IO::String, but now that functionality is built into the core.
>>
>> By your last paragraph, I'm really lost.  Since you're already
>> passing the request as a file handle, I'm guessing that Catalyst
>> creates the tempororary file for the *response* body.  Can you
>> please clarify?  Also, what do you mean by "de-chunking"?  Is that
>> the same think as re-assembling?
>>
>> Wish I could give a better answer.  Let me know if this helps.
>>
>> -Jim
>>
>>
>>
>> On Tue, 2 Jul 2013, Bill Moseley wrote:
>>
>> For requests that are chunked (Transfer-Encoding: chunked and no
>> Content-Length header) calling $r->read returns unchunked data
>> from the
>> socket.
>> That's indeed handy.  Is that mod_perl doing that un-chunking
>> or is it
>> Apache?
>>
>> But, it leads to some questions.   
>>
>> First, if $r->read reads unchunked data then why is there a
>> Transfer-Encoding header saying that the content is chunked?  
>> Shouldn't
>> that