On Sep 18, 2014, at 5:21 PM, Dagfinn Ilmari Mannsåker <[email protected]> wrote:
>
> "Daniel J. Luke" <[email protected]> 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
+========================================================+
| *---------------- [email protected] ----------------* |
| *-------------- http://www.geeklair.net -------------* |
+========================================================+
| Opinions expressed are mine and do not necessarily |
| reflect the opinions of my employer. |
+========================================================+
_______________________________________________
List: [email protected]
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/[email protected]/
Dev site: http://dev.catalyst.perl.org/
