by Dick Lane -
Number of replies: 5
While investigating a report of haphazard failures for a login, I discovered more than 11,000 occurrences of
      File does not exist: /opt/webwork/webwork2/htdocs/css/tabber.css
in /var/log/apache2/error.log (since August 28).

Note:     find /opt/webwork -name tabber.css -print    has an empty report.

webwork2/conf/global.conf.dist  for revision 7025 includes
    # Location of Tabber script, used to generate tabbed widgets.
    $webworkURLs{tabber}            = "$webworkURLs{htdocs}/js/tabber.js";
which I replicated into my current global.conf  [FWIW: tabber.js does exist].

Q:  in the short run (i.e., without awaiting an explanation), would it be benign if I commented-out that single command in global.conf and restarted apache (or will further changes be needed) ?

In reply to Dick Lane

Re: tabber.css

by Michael Gage -
Hi Dick,

I don't think that will solve the problem although it also won't hurt.

A more likely fix
is to delete the line in the conf/templates/math2/system.template file (there is one for each of math2 and math3) which is near the top and that looks like:

<link rel="stylesheet" ..... ...... /css/tabber.css"/>

see if that fixes the problem.

Alternatively I can include the files tabber.js and tabber.css in trunk -- supposedly they are not being used yet but they will be as we continue to develop the new AJAXy interface.

The are currently in my development branch of the svn.

-- Mike

In reply to Michael Gage

Re: tabber.css

by Dick Lane -
Thanks, Mike --- after zapping that line in the math2 version (the default theme for our courses) and restarting, errors citing tabber.css have ceased.

For reference, slightly before I did that, there were about 25,000 lines in error.log with three main contributors (rounded counts below)
11,200   /opt/webwork/webwork2/htdocs/css/tabber.css
  6,750   /opt/webwork/webwork2/htdocs/js/addOnLoadEvent.js
  4,100   /opt/webwork/webwork2/htdocs/images/favicon.ico

I found favicon.ico in htdocs and put a copy into its images subdirectory.

I did not find  addOnLoadEvent.js  anywhere.  About 15 minutes after previous count, there are about 100 more errors involving it.

With two of those noise sources being silent now, I have been able to notice a moderately frequent repetition in error.log of
    Subroutine install_problem_grader redefined at (eval 2899) line 2, <MACROFILE> chunk 1.
[520 occurrences in whole error.log which now has 25,150 lines]
The eval number varies, but line 2 and chunk 1 are uniformly cited.

PS:  Since this installation began with a liveDVD (2.4 on Ubuntu 10.04LTS 64-bit) and plain "svn update" has been used subsequently for WeBWorK, and since I already have tabber.js, I infer that tabber.js is already in trunk.

In reply to Dick Lane

Re: tabber.css

by Michael Gage -
Hi Dick,

The "install_problem_grader redefined (and a few other redefined messages) have been around for some time -- they are hard to track down because they occur at run time when the .pg problems are being processed. I'll take another crack at it at some point. I too would like to have a really clean error log --partially because it works better but mostly for aesthetics. I don't like spurious error messages.

I found the reference to addOnLoadEvent in The simplest solution in this case seems to be to add "addOnLoadEvent.js" to webwork2/htdocs/js directory and I have done that. Mostly it is not used yet in coloring the answer blanks indicating whether an answer is correct or not.

That .js file and tabber will be used more extensively in the next release to give some of the instructor tools a more AJAXy feel. Some of the .css customization on those modules still needs work, so I tried to separate out what was ready for use now and what should wait for a month or two.

I've duplicated your fix for the favicon.ico file and placed copies in both
htdocs and htdocs/images. See if this quiets down the errors. In some cases
I believe browsers search for the favicon.ico in the very top directory (not involving webwork) which in my case is /opt/htdocs but I haven't taken the time to verify this behavior.

Update the js directory from svn and let me know if this quiets down the error log.

Thanks very much for taking the time to investigate this and to give me a clear report of what errors are occurring on your system.

-- Mike

In reply to Michael Gage

install_problem_grader redefined

by D. Brian Walton -
I noticed this error when I was looking through our log files looking for clues to why our server bogs down occasionally (not necessarily due to high load). I found one example of a common culprit:

Every problem that I have written that uses ProblemRandomize (and I try to make this my standard practice) will throw this warning to the error log file. Consequently, my log file is full of many such warnings.

Is there a reason the subroutine was redefined instead of using a reference to a install_problem_grader routine?

- Brian

D. Brian Walton
James Madison University
In reply to D. Brian Walton

Re: install_problem_grader redefined

by Dick Lane -
I think Brian has identified an important culprit.

For my classes, problemRandomize is invoked via my which offers a "Get new version" button only after either (a) complete success before due-date or (b) after due-date [and never changes scoring for a student's performance which is always based on their original version].

About 40% of my recent server errors, e.g., 406 items reported by 
        tail -1000 error.log | fgrep install_problem | wc
(done in /var/log/apache2) may be attributable to this.

Is some change needed so that problemRandomize will "play nicely with friends"?

It might be useful to augment existing documentation to clarify the scope of problemRandomize.  E.g., it's fairly clear that it will not modify custom error-checking, but which standard checkers are also immune to being re-randomized?  More subtly, are there standard checkers which can be re-randomized but with non-obvious side-effects?