Item1295: Unwanted stack trace with log file permissions error

previously (fw 1.0.0 etc), if we were unable to write to the data/log*.txt files, we would write to STDERR - thus the apache error log.

this was useful for setting a wiki to read only by brute force - chmod -R 777 data pub

the log refactoring has changed this to become a fatal error - I'm not sure if this is a desirable result in a patch release.

Software error:

ERROR: Could not write "2009-03-14T01:31:06Z warning | Plugins: could not fully register SpreadSheetPlugin, no plugin topic" to /var/www/html/Release01x00/core/data/warn200903.txt: Permission denied

For help, please send mail to the webmaster (root@localhost), giving this error message and the time and date of the error.
Software error:

[Sat Mar 14 12:31:06 2009] view: ERROR: Could not write "2009-03-14T01:31:06Z warning | Plugins: could not fully register SpreadSheetPlugin, no plugin topic" to /var/www/html/Release01x00/core/data/warn200903.txt: Permission denied
 at /usr/lib/perl5/5.8.8/CGI/Carp.pm line 314
   CGI::Carp::realdie('[Sat Mar 14 12:31:06 2009] view: ERROR: Could not write "2009...') called at /usr/lib/perl5/5.8.8/CGI/Carp.pm line 400
   CGI::Carp::die('ERROR: Could not write "2009-03-14T01:31:06Z warning | Plugin...') called at /var/www/html/Release01x00/core/lib/Foswiki/Logger/PlainFile.pm line 67
   Foswiki::Logger::PlainFile::log('Foswiki::Logger::PlainFile=HASH(0x9f41aec)', 'warning', 'Plugins: could not fully register SpreadSheetPlugin, no plugi...') called at /var/www/html/Release01x00/core/lib/Foswiki/Plugins.pm line 191
   Foswiki::Plugins::load('Foswiki::Plugins=HASH(0x9ae05f0)', 'undef') called at /var/www/html/Release01x00/core/lib/Foswiki/Users.pm line 247
   Foswiki::Users::initialiseUser('Foswiki::Users=HASH(0x9b49c08)', 'guest') called at /var/www/html/Release01x00/core/lib/Foswiki.pm line 1503
   Foswiki::new('Foswiki', 'undef', 'Foswiki::Request=HASH(0x9ab435c)', 'HASH(0x9a9b910)') called at /var/www/html/Release01x00/core/lib/Foswiki/UI.pm line 170
   Foswiki::UI::execute('Foswiki::Request=HASH(0x9ab435c)', 'CODE(0x9ab40c8)', 'view', 1) called at /var/www/html/Release01x00/core/lib/Foswiki/UI.pm line 120
   Foswiki::UI::handleRequest('Foswiki::Request=HASH(0x9ab435c)') called at /var/www/html/Release01x00/core/lib/Foswiki/Engine/CGI.pm line 26
   Foswiki::Engine::CGI::run('Foswiki::Engine::CGI=HASH(0x9958050)') called at /var/www/html/Release01x00/core/bin/view line 45

For help, please send mail to the webmaster (root@localhost), giving this error message and the time and date of the error.

-- SvenDowideit - 15 Mar 2009

I think it is, personally, and I can confirm this, it is by design. I have had a number of support requests where I was unable to help effectively because no log had been written as a result of permissions. It's silly to have a log that can't be written to.

-- CrawfordCurrie - 15 Mar 2009

So let me understand

Before if Foswiki could not write the log it would be silent about it or just log it in Apache error log?

And now the whole thing crashes?

Well. I would think this error would manifest itself 10 milliseconds after the person installing Foswiki tries to view the very first page in Foswiki. And then he fixes his access rights for the logging and is happy. Is that correctly understood?

Why is that problem and why a release blocker??

And if I understand it right - I would say it is essential that the newbie admin is alerted very clearly. If you cannot write to a log it is most likely the access rights of the data directory which is wrong. Then you later get problems creating webs or creating the next log2009XX file when XX changes the 1st in the month. I am not sure that it is such a bad thing to alert in a noisy way.

-- KennethLavrsen - 15 Mar 2009

shrug. as I said above, this is a bug report indicating that there is a functionality change in a patch release. In this case yet another ugly stack trace,

I also indicate a use case in which it is an issue.

I guess this has given me a taste of the responses that some people have found so frustrating - their bug reports are classed as irrelevant by the 'developers', rather than a solution found.

/me chooses to go back into lurking mode too.

-- SvenDowideit - 15 Mar 2009

I was concerned about the ugliness of the stack trace, but I felt that it was better to inform early than allow the issue to persist, and that an admin would be able to cope with a stack trace without voiding their bowels.

Confirming this and dropping it to normal status and changed the headline from "unable to write log file is newly a fatal error". It should be fixed, but so should many other Normals.

-- CrawfordCurrie - 16 Mar 2009

Sven. Your bug report is relevant and need fixing. It was more what to do about it that was up for discussion. And it seems Crawford and I feel that it is better to tell loudly to the bloke installing Foswiki that his ACLs need fixing right away than to run on silently.

But showing an ugly stacktrace is not the best way and should be replaced by a proper help so people can fix it without getting on IRC crying.

So I agree that this is a Normal rated bug report where the desired fix is a proper message instead of a stack trace.

And thanks for raising the bug report Sven

-- KennethLavrsen - 16 Mar 2009