Re: Weird mod_perl issue, popping up error on error

First of all, while it may seem convenient, at least this error stems from your use of Apache::Reload:

Apache2::Reload: Can't locate (set by Moose)
[download]

This happens because Apache::Reload tries to reload a package which has been created not from a file but from within Moose. When reloading, Apache::Reload tries to find the file named (set by Moose), which predictably does not exist. This can be harmless but might also mean that the package is not recreated by Moose when you would expect it to. Stop and restarting Apache instead of trying to "smartly" reload it would help here.

[Sat Nov 21 14:13:05 2015] Tools.pm: Prototype mismatch: sub Want::Too
+ls::EXDEV: none vs () at /srv/www/site.net/www/cgi-bin/admin/Want/Too
+ls.pm line 506.
[download]

Maybe the above error also stems from reloading Want::Tools, which overwrites/redeclares the EXDEV subroutine with a slightly different prototype, or you have predeclared EXDEV via:

sub EXDEV;
[download]

... but later declare it as sub EXDEV() { ... } or use constant EXDEV => ....

Lastly, let me advise strongly against having any module below /srv/www/site.net/www/cgi-bin/ which is not a .pl script. Keep your configuration files and modules and other stuff out of cgi-bin, as a webserver misconfiguration could expose them (and include passwords or module versions or expose bugs in the modules that would be much harder to find otherwise).

Comment on Re: Weird mod_perl issue, popping up error on error_log Select or Download Code

Replies are listed 'Best First'.
Re^2: Weird mod_perl issue, popping up error on error_log by ultranerds (Hermit) on Nov 21, 2015 at 17:59 UTC
H, Thanks for the reply. Gotta admit, I'm confused =) Maybe the above error also stems from reloading Want::Tools, which overwrites/redeclares the EXDEV subroutine with a slightly different prototype, or you have predeclared EXDEV via: Mmm, well I do include it in the startup.pl: `use Want::View; use Want::Tools; use Want::Daily; use Want::Directory; ...etc` [download] ...and then its also included in some of the other custom perl modules (and some .cgi scripts). The problem is, my dev server isn't currently using mod_perl, so it would be hard to take those duplicate "use" statements out of the main code, and rely on them being loaded on the startup.pl boot. Maybe I will get the mod_perl stuff going on my dev server, and then see if I can get the errors to go away. Its a shame, as I was hoping not to use mod_perl on the dev server (as it causes a headache with caching of scripts, when you don't want to see a cached version ;)) Lastly, let me advise strongly against having any module below /srv/www/site.net/www/cgi-bin/ which is not a .pl script. Keep your configuration files and modules and other stuff out of cgi-bin, as a webserver misconfiguration could expose them (and include passwords or module versions or expose bugs in the modules that would be much harder to find otherwise). Thanks for the advice. Its a bit tricky, as all those modules are part of a 3rd party system (and we've bolted out own code on). Also, they can't actually view the .pm files (only .cgi scripts will run in that folder, and all the rest would give 500 IS errors :)) Cheers Andy	[reply] [d/l]

Replies are listed 'Best First'.

Re^2: Weird mod_perl issue, popping up error on error_log
by ultranerds (Hermit) on Nov 21, 2015 at 17:59 UTC

Maybe the above error also stems from reloading Want::Tools, which overwrites/redeclares the EXDEV subroutine with a slightly different prototype, or you have predeclared EXDEV via:

use Want::View;
use Want::Tools;
use Want::Daily;
use Want::Directory;
...etc
[download]

Lastly, let me advise strongly against having any module below /srv/www/site.net/www/cgi-bin/ which is not a .pl script. Keep your configuration files and modules and other stuff out of cgi-bin, as a webserver misconfiguration could expose them (and include passwords or module versions or expose bugs in the modules that would be much harder to find otherwise).

[reply]
[d/l]