Item9382: Improve error reporting if Foswiki is unable to read LocalSite.cfg

Configure::Load.pm when it loads Foswiki.spec and LocalSite.cfg, uses "do" and tests $@ they fail.

The perl "do" should use $! for the error, not $@. Result was a non-readable, but present LocalSite.cfg was silently failing to load. The $INC{'LocalSite.cfg'} doesn't get set, and foswiki.fcgi fails with an uninitialized variable - then uses "NOT SET" for various paths, and fails.

Need also to note that in a SuexecUserGroup environment, foswiki.fcgi will run under the server's user/group, and have all sorts of file access issues. If Suexec will be used, fastcgi must be configured for FastCgiWrapper  /usr/sbin/suexec2 (or as appropriate for the local installation) at the server level. Not valid in virtual hosts.

-- GeorgeClark - 24 Jul 2010

From perldoc -f do

If "do" cannot read the file, it returns undef and sets $! to
the error.  If "do" can read the file but cannot compile it, it
returns undef and sets an error message in $@.

so I guess both have to be handled.

-- CrawfordCurrie - 24 Jul 2010

I've committed a fix - however I don't understand some of the legacy code in Load.pm. It did have a test for $! == 2. But $! is a text error message, so I'm not sure what that's trying to do.

-- GeorgeClark - 25 Jul 2010

Read the comment... if the file doesn't exist, $! is set to 2 (No such file or directory), and it's a valid case, this file doesn't have to exist. Oh, and $! has magic, if it's used as an number, it returns the value of errno, otherwise it returns the string. So you can do that:

$ perl -le'$!=2;die$!'
No such file or directory at -e line 1.

Pasting perldoc perlvar:

       $!      If used numerically, yields the current value of the C "errno"
               variable, or in other words, if a system or library call fails,
               it sets this variable.  This means that the value of $! is
               meaningful only immediately after a failure:
[...]
               If used as a string, yields the corresponding system error
               string.  You can assign a number to $! to set errno if, for
               instance, you want "$!" to return the string for error n, or
               you want to set the exit value for the die() operator.
               (Mnemonic: What just went bang?)

So, if you don't understand something, read the comments. If the comments are not good enough, read the manual. But here basically, you removed a functionality to fix a "bug" which I still fail to understand.

-- OlivierRaginel - 25 Jul 2010

Hi Babar - copying over my comment from the list.

Maybe the problem is that $! returns a string, not a number? (Nope - I see you've explained that above).

The problem I was "fixing" was that if the file exists but cannot be read, it fails silently and foswiki.fcgi fails with uninitialized variables. Spent 5 hours trying to understand why LocalSite.cfg variables were undefined during foswiki.fcgi initialization, adding print statements here & there to find where the failure was. (It was running under a different user/group and couldn't read LSC.) There was no error message reported anywhere.

I suspect it all still works because configure uses Load in a try/catch? I couldn't find anything I broke with the change. I've renamed, chown'd chmodded, corrupted, and otherwise broke LSC and configure was still happy. But there was finally an error in the log if the file could not be read.

I'll revert my change - I still don't get why the failure to read under control of fcgi was not reported. The code as originally written doesn't work, but it appears my try doesn't either. Maybe I'll add a message to foswiki.fcgi to question if LocalSite.cfg is readable by the fcgi process if $INC{LocalSite.cfg} is undefined.

-- GeorgeClark - 25 Jul 2010

Ok, then maybe it was reporting an error 2, File doesn't exist, for whatever odd reason, and my test was clearing that without any warning.

What we could do is split the http://trac.foswiki.org/browser/trunk/core/lib/Foswiki/Configure/Load.pm?rev=8293#L70 test to also print out some warning that this file couldn't be read. We dont want it to be a fatal error, but we can yell out some warnings

-- OlivierRaginel - 25 Jul 2010

The conditions that created this were a corner case: Running under "suexec" results in LocalSite.cfg permissions of 600. Misconfigured mod_fastcgi was running under Apache user, so mod_fastcgi could not read LocalSite.cfg. For some reason, the reported error from perl ($!) was "file not found" instead of the permission error.

Since LocalSite.cfg should always be readable on a running system, it's probably safe and reasonable to print any $! or $@ to STDERR in Load.pm. It gives the admin on a broken system a bit more to go on. foswiki.fcgi should also detect that LocalSite.cfg is not loaded and die gracefully with a meaningful error.

-- GeorgeClark - 25 Jul 2010

Agreed, I would close this one after your latest fixes George. Maybe backport to 1.0.10?

-- OlivierRaginel - 27 Jul 2010

Commenting is disabled while not logged in