From jjn1056 at yahoo.com Mon Sep 15 22:59:54 2014 From: jjn1056 at yahoo.com (John Napiorkowski) Date: Mon, 15 Sep 2014 15:59:54 -0700 Subject: [Catalyst] New Development Branch "Holland" for Perl Catalyst now open Message-ID: <1410821994.27441.YahooMailBasic@web140804.mail.bf1.yahoo.com> Hey all!, One more real Catalyst release this year? Wanna help? Here's the blog post http://jjnapiorkowski.typepad.com/modern-perl/2014/09/new-perl-catalyst-development-branch-holland-now-open.html Thanks! jnap From dluke at geeklair.net Thu Sep 18 21:01:08 2014 From: dluke at geeklair.net (Daniel J. Luke) Date: Thu, 18 Sep 2014 17:01:08 -0400 Subject: [Catalyst] FastCGI startup strangeness Message-ID: <32325837-E2F2-4A88-9298-D9068AF57AA6@geeklair.net> 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 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. | +========================================================+ From ilmari at ilmari.org Thu Sep 18 21:21:49 2014 From: ilmari at ilmari.org (Dagfinn Ilmari =?utf-8?Q?Manns=C3=A5ker?=) Date: Thu, 18 Sep 2014 22:21:49 +0100 Subject: [Catalyst] FastCGI startup strangeness In-Reply-To: <32325837-E2F2-4A88-9298-D9068AF57AA6@geeklair.net> (Daniel J. Luke's message of "Thu, 18 Sep 2014 17:01:08 -0400") References: <32325837-E2F2-4A88-9298-D9068AF57AA6@geeklair.net> Message-ID: "Daniel J. Luke" 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. 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. > 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? -- "I use RMS as a guide in the same way that a boat captain would use a lighthouse. It's good to know where it is, but you generally don't want to find yourself in the same spot." - Tollef Fog Heen From dluke at geeklair.net Fri Sep 19 20:10:37 2014 From: dluke at geeklair.net (Daniel J. Luke) Date: Fri, 19 Sep 2014 16:10:37 -0400 Subject: [Catalyst] FastCGI startup strangeness In-Reply-To: References: <32325837-E2F2-4A88-9298-D9068AF57AA6@geeklair.net> Message-ID: <186B2F16-2617-4246-AF27-A0BAEF9C9370@geeklair.net> On Sep 18, 2014, at 5:21 PM, Dagfinn Ilmari Manns?ker wrote: > > "Daniel J. Luke" 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. | +========================================================+