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