[Catalyst] FastCGI startup strangeness

[Daniel J. Luke]

On Sep 18, 2014, at 5:21 PM, Dagfinn Ilmari Mannsåker <ilmari at ilmari.org> wrote:
> 
> "Daniel J. Luke" <dluke at geeklair.net> writes:
> 
>> I noticed today that an app I'm working on will start fine only if the
>> user who is running the app can read the current directory (ie, if I'm
>> starting it as a user dedicated to running the app, that user must
>> have read permission on CWD).
>> 
>> Couldn't load class (MYAPP::Script::FastCGI) because: Can't locate MYAPP/Script/FastCGI.pm:   Permission denied at /path/to/perl-5.20.0/lib/site_perl/5.20.0/Catalyst/ScriptRunner.pm line 13.
>> 	Catalyst::ScriptRunner::find_script_class("Catalyst::ScriptRunner", "MYAPP", "FastCGI") called at /path/to/perl/perl-5.20.0/lib/site_perl/5.20.0/Catalyst/ScriptRunner.pm line 42
>> 	Catalyst::ScriptRunner::run("Catalyst::ScriptRunner", "MYAPP", "FastCGI") called at /path/to/MYAPP/script/MYAPP_fastcgi.pl line 4
>> 
>> strace shows the difference between a successful launch and a failed
>> one is whether we get EACCESS or ENOENT when looking for
>> ./MYAPP/Script/FastCGI.pm
> 
> This is due to require as of 5.18 no longer silently ignoring errors
> when trying to load a module:
> 
>    require dies for unreadable files
> 
>    When require encounters an unreadable file, it now dies. It used
>    to ignore the file and continue searching the directories in @INC
>    [perl #113422].
> 
> https://metacpan.org/pod/perl5180delta#require-dies-for-unreadable-files
> 
> Combined with the fact that Catalyst::ScriptRunner tries to load the
> optional (but in your case non-existent) MYAPP::Script::FastCGI, and
> that '.' is in @INC by the default, it gives this (somewhat annoying)
> behaviour.

would it be worthwhile for Catalyst::ScriptRunner to check if the file exists before trying to load it?

> For daemons it is generally a good idea to cd to / or some
> application-specific directory before starting up, to avoid e.g. it
> accidentally hanging onto a mount point.

true, and for the 'general' case, I don't hit this issue. I noticed it in my DEV instance where I was in my $HOME and trying to run the app as the 'normal' app user by hand instead of with the startup scripts we normally use.

>> failure:
>> stat("./MYAPP/Script/FastCGI.pmc", 0x7fffa8eba720) = -1 EACCES (Permission denied)
>> stat("./MYAPP/Script/FastCGI.pm", 0x7fffa8eba660) = -1 EACCES (Permission denied)
>> 
>> success:
>> stat("./MYAPP/Script/FastCGI.pmc", 0x7fff80e76db0) = -1 ENOENT (No such file or directory)
>> stat("./MYAPP/Script/FastCGI.pm", 0x7fff80e76cf0) = -1 ENOENT (No such file or directory)
>> 
>> I didn't see this documented anywhere - am I missing some obvious reason why this behavior is desired?

--
Daniel J. Luke                                                                   
+========================================================+                        
| *---------------- dluke at geeklair.net ----------------* |                          
| *-------------- http://www.geeklair.net -------------* |                          
+========================================================+                        
|   Opinions expressed are mine and do not necessarily   |                          
|          reflect the opinions of my employer.          |                          
+========================================================+