Re: [EXT]Re: error trying to start httpd with mod_perl enabled

2023-10-27 Thread Johnson, Bruce E - (bjohnson)
Yep, that was it.

I thought it had been set to disabled but it was not.

On Oct 27, 2023, at 9:31 AM, Andy Osborne  wrote:


External Email

Rocky has SELinux on by default I think.  Could be that getting in the way ?

What does "getenforce" say ?

Andy


On 27/10/2023 13:54, Johnson, Bruce E - (bjohnson) wrote:
I’m setting up a new server to replace one that is currently running fine (I am 
changing the database for my app from oracle to Postgres and need to test this 
before doing the switchover.)

I’ve looked at the apache settings on both systems, file permissions, etc and 
they look the same, but httpd fails at startup with the following error:


[Thu Oct 26 16:11:46.962322 2023] [perl:error] [pid 96852:tid 96852] Can't 
locate /home/allwebfiles/perl/startup.pl:   /home/allwebfiles/perl/startup.pl: 
Permission denied at (eval 2) line 1.\n
[Thu Oct 26 16:11:46.962564 2023] [perl:error] [pid 96852:tid 96852] Can't load 
Perl file: /home/allwebfiles/perl/startup.pl for server 
dhbroomscheduling4.pharmacy.arizona.edu:0,
 exiting..

The file permissions are correct

 ls -l /home/allwebfiles/perl/startup.pl
-rwxr-xr-x. 1 webworker apache 515 Oct 26 16:11 
/home/allwebfiles/perl/startup.pl

The contents of startup.pl seem to be correct (the only change was the dbd line 
in the DBI startup.)

#!/usr/bin/perl
use lib qw(/usr/lib64/perl5 /usr/share/perl5 /usr/local/lib64/perl5 
/home/allwebfiles/perl/LocalModules /usr/lib64/perl5/vendor_perl/Bundle);

use Apache::DBI;
Apache::DBI->connect_on_init ("dbi:Pg:host=redacted;port=5432", “xxx", 
“xxx", {
PrintError => 1, # warn() on errors
RaiseError => 0, # don't die on error
AutoCommit => 1, # commit executes immediately
   }
  );
use CleanCGI ();
use CGI ();
CGI->compile(':all');


use DBI ();
use Apache2;
1;


This is the correct location of perl, and all the use lib locations are correct

which perl
/usr/bin/perl


System:

cat /etc/redhat-release
Rocky Linux release 9.2 (Blue Onyx)

 perl -v

This is perl 5, version 32, subversion 1 (v5.32.1) built for 
x86_64-linux-thread-multi
(with 52 registered patches, see perl -V for more detail)

httpd -v
Server version: Apache/2.4.53 (Rocky Linux)
Server built:   Apr 28 2023 00:00:00

(And yes mod_perl is installed )

The working system is an older distro of Rocky Linux 8.5, but otherwise all is 
identical, with the exceptions I”m connecy=ting to Oracle on it not Postgres.

(I can connect and query the database using a script on the command line on the 
new system so I know all of that works)

--
Bruce Johnson
University of Arizona
College of Pharmacy
Information Technology Group

Institutions do not have opinions, merely customs



--
Andy Osborne - Technical Director
Conscious Solutions, Royal London Buildings, Baldwin St. Bristol BS1 1PN
UK Co. Reg No. 4966976  VAT No. 826 2638 21 https://www.conscious.co.uk/
tel:01173250200 ddi:01173250204  https://www.linkedin.com/in/andyosborne


--
Bruce Johnson
University of Arizona
College of Pharmacy
Information Technology Group

Institutions do not have opinions, merely customs




Re: [EXT]Re: error trying to start httpd with mod_perl enabled

2023-10-27 Thread John D Groenveld
In message , "Johnson, Bruce 
E - (bjohnson)" writes:
>apachectl configtest
>
>[Fri Oct 27 08:41:49.204868 2023] [so:warn] [pid 97206:tid 97206] AH01574: =
>module perl_module is already loaded, skipping
>
>Syntax OK
>
>
># su - webworker
>$ perl -c /home/allwebfiles/perl/startup.pl
>
>
>[webworker@dhbroomscheduling4 ~]$ perl -c /home/allwebfiles/perl/startup.pl
>
>/home/allwebfiles/perl/startup.pl syntax OK

Maybe try an strace(1) to find the failed open(2):
# strace -f -e open httpd -X

John
groenv...@acm.org


Re: [EXT]Re: error trying to start httpd with mod_perl enabled

2023-10-27 Thread Johnson, Bruce E - (bjohnson)


On Oct 27, 2023, at 6:34 AM, John D Groenveld  wrote:


The contents of startup.pl seem to be correct (the only change was
the dbd line in the DBI startup.)

Two tests come to mind that might help you debug:
# apachectl configtest


apachectl configtest

[Fri Oct 27 08:41:49.204868 2023] [so:warn] [pid 97206:tid 97206] AH01574: 
module perl_module is already loaded, skipping

Syntax OK


# su - webworker
$ perl -c /home/allwebfiles/perl/startup.pl


[webworker@dhbroomscheduling4 ~]$ perl -c /home/allwebfiles/perl/startup.pl

/home/allwebfiles/perl/startup.pl syntax OK


--
Bruce Johnson
University of Arizona
College of Pharmacy
Information Technology Group

Institutions do not have opinions, merely customs




RE: [EXT]

2021-02-07 Thread James Smith
This can be a bigger gain if you are limited with memory as multiple processes 
will share the same block of physical memory { so limiting swap } – this is one 
of the advantages of the mod_perl approach over the app approach in things like 
dancer. You have the flexibility to include what you want – if you have a 
single webpage or service which needs a large number of modules – but is 
perhaps used once in every 100k requests you don’t have to load it in at the 
start of the process, and you have the flexibility to choose how much or how 
little you want of the framework preloaded…


From: Adam Prime 
Sent: 07 February 2021 13:45
To: Steven Haigh 
Cc: James Smith ; modperl@perl.apache.org
Subject: Re: [EXT]

There is one other thing you can do relatively easily that may get you a 
marginal gain when Apache spins up new children. Load some or all of your Perl 
dependencies before Apache forks. There is also an opportunity to load other 
static resources at this time, but that can get a little more involved and/or 
confusing. There is some documentation here:

https://perl.apache.org/docs/2.0/user/handlers/server.html#Startup_File 
[perl.apache.org]<https://urldefense.proofpoint.com/v2/url?u=https-3A__perl.apache.org_docs_2.0_user_handlers_server.html-23Startup-5FFile=DwMFaQ=D7ByGjS34AllFgecYw0iC6Zq7qlm8uclZFI0SqQnqBo=oH2yp0ge1ecj4oDX0XM7vQ=kwRJ9OU2GaHG3eTqlSv3NGFCM8bbDVVw6VWYGivfszw=sT5APUQZ6MWHqhwLVLrTEK4xPf6OEANKV0EePFJ1L6Y=>

Adam



On Feb 7, 2021, at 8:15 AM, Steven Haigh 
mailto:net...@crc.id.au>> wrote:

In fact, I just realised that 'ab' test is rather restrictive So here's a 
bit more of an extended test:

# ab -k -n 1000 -c 32

Apache + ExecCGI:
Requests per second:14.26 [#/sec] (mean)
Time per request:   2244.181 [ms] (mean)
Time per request:   70.131 [ms] (mean, across all concurrent requests)

Apache + mod_perl (ModPerl::PerlRegistry):
Requests per second: 132.14 [#/sec] (mean)
Time per request:   242.175 [ms] (mean)
Time per request:   7.568 [ms] (mean, across all concurrent requests)

Interestingly, without Keepalives, the story is much the same:

# ab -n 1000 -c 32

Apache + ExecCGI:
Requests per second:14.15 [#/sec] (mean)
Time per request:   2260.875 [ms] (mean)
Time per request:   70.652 [ms] (mean, across all concurrent requests)

Apache + mod_perl (ModPerl::PerlRegistry):
Requests per second:154.48 [#/sec] (mean)
Time per request:   207.140 [ms] (mean)
Time per request:   6.473 [ms] (mean, across all concurrent requests)

Running some benchmarks across various parts of my site made me realise I also 
had some RewriteRules in the apache config that still had H=cgi-script - 
changed those to H=perl-script and saw similar improvements:

ExecCGI - Requests per second:11.84 [#/sec] (mean)
mod_perl - Requests per second:130.97 [#/sec] (mean)

That's quite some gains for a days work.

--
Steven Haigh  net...@crc.id.au<mailto:net...@crc.id.au>  
https://www.crc.id.au 
[crc.id.au]<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.crc.id.au_=DwMFaQ=D7ByGjS34AllFgecYw0iC6Zq7qlm8uclZFI0SqQnqBo=oH2yp0ge1ecj4oDX0XM7vQ=kwRJ9OU2GaHG3eTqlSv3NGFCM8bbDVVw6VWYGivfszw=xsyidls-ez8g3gIshJPO4FIGzGjiIp_qnzQ1yujeNK4=>

On Sun, Feb 7, 2021 at 23:58, Steven Haigh 
mailto:net...@crc.id.au>> wrote:

Interestingly, I did get things working with ModPerl::PerlRegistry.

What I couldn't find *anywhere* is that the data I was loading in Template 
Toolkit was included in the file in the __DATA__ area - which causes mod_perl 
to fall over!

The only way I managed to find this was the following error in the *system* 
/var/log/httpd/error_log (didn't show up in the vhost error_log!):
readline() on unopened filehandle DATA at 
/usr/lib64/perl5/vendor_perl/Template/Provider.pm line 638.

Took me a LONG time to find a vague post that reading in lines from  
kills mod_perl. Not sure why - but I stripped all the templates out and put 
them in a file instead and re-wrote that bit of code, and things started 
working.

I had to fix a few lib path issues, but after getting my head around that, most 
things seem to work as before - however I don't notice much of an improvement 
in execution times, I do see this improvement using 'ab -n 100 -c32':

Apache + ExecCGI: Requests per second:13.50 [#/sec] (mean)
Apache + mod_perl: Requests per second:59.81 [#/sec] (mean)

This is obviously a good thing.

I haven't gotten into the preload or DBI sharing yet - as that'll end up 
needing a bit of a rewrite of code to take advantage of. I'd be open to 
suggestions here from those who have done it in the past to save me going down 
some dead ends :D


--
Steven Haigh  net...@crc.id.au<mailto:net...@crc.id.au>  
https://www.crc.id.au 
[crc.id.au]<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.crc.id.au_=DwMFaQ=D7ByGjS34AllFgecYw0iC6Zq7qlm8uclZFI0SqQnqBo=oH2yp0ge1ecj4oDX0XM7vQ=kwRJ9OU2GaHG