Forum archive 2000-2006

ymarkov - Problem with

ymarkov - Problem with

by Arnold Pizer -
Number of replies: 0
inactiveTopicProblem with topic started 9/5/2003; 9:26:23 AM
last post 9/8/2003; 7:15:07 PM
userymarkov - Problem with  blueArrow
9/5/2003; 9:26:23 AM (reads: 1080, responses: 3)
We have run into the following problem which seems serious, though could be related to set-up. We changed to v.1.9 and all classes worked fine for the first 10 days. However two days ago dumped cores (20MB each) at various places: .../webwork/system/cgi/cgi-scripts/ and in the few of the .../course/html/tmp/ directories At about the same time the buttons "Work on problem set", "get hard copy" and those underneeth them stopped working. One can login and access the prof. page. As far as I can see all (most) tasks there work fine. We run Redhat 7.3, a few day ago we had to apply a fix to the dvi2png and eps2png scripts removing the -nosetpage switch. Could those be related? Thank you for your input.

Regards, Yavor Markov - Rutgers U.

<| Post or View Comments |>

userymarkov - Re: Problem with  blueArrow
9/7/2003; 7:25:01 PM (reads: 1280, responses: 0)
Some clarification on the issue above

Any perl routine that has to look at the problems fails, while login and database up-dates are fine. After a reboot of the machine the system was functioning without noticable problems for 48 hours before the same issue happened again. Again a core was dumped at the system/cgi/ and at the system/cgi/cgi-scripts/ directories. Strings search shows the processProblem8 string. On the set-up side, which of the cgi directories should be given as the cgi scripts directory? we have always gone with /cgi-bin/webwork/system/cgi/cgi-scripts/ where the full copies of the scripts are placed, but may be it has to be /cgi-bin/webwork/system/cgi/ where the shell scrips reffering to the actual scripts are.

Thanks again,


<| Post or View Comments |>

userArnold K. Pizer - Re: Problem with  blueArrow
9/8/2003; 10:24:19 AM (reads: 1307, responses: 0)

Hi Yavor,

We have not head of any other reports of core dumps.  It's hard to imagine that the nosetpage switch issue would have anything to do with core dumps.

To answer your question about  /cgi-bin/webwork/system/cgi/cgi-scripts/ vs /cgi-bin/webwork/system/cgi/  .   First if you follow the setup instructions, everything should be set correctly.  If this is not set correctly, nothing will work so that shouldn't be the source of your problems.  It seems strange to me that you are getting core dumps in /cgi-bin/webwork/system/cgi/ since unless you are debugging, that directory should be bypassed by WeBWorK.

Now for the answer.  The shell scripts are only used for debugging but WeBWorK normally automatically bypasses them.  Look at .../webwork/system/lib/ which is created by the setup process.  You will see the 2 lines:

(1) $cgiWebworkURL = "/cgi-bin/webwork/system/"; 

(this may be different depending on how you set things up).  But no matter how you set up your system, this is supposed to point to (look at Apache's config file) .../webwork/system/cgi/ which is where the shell scripts reside. However, the next line reads:

(2) $cgiWebworkURL .= "cgi-scripts/" unless $cgiDebugMode; (which means append cgi-scripts/ to the path).

Thus unless $cgiDebugMode is set to 1 (by default it's set to 0), the shell scrips are bypassed since $cgiWebworkURL = "/cgi-bin/webwork/system/cgi-scripts/"; 





<| Post or View Comments |>

userJohn Jones - Re: Problem with  blueArrow
9/8/2003; 7:15:07 PM (reads: 1248, responses: 0)
As far as the core dumps go, have you looked around for other problems such as running out of disk space or file nodes? The command "df" should tell you about the former and "df -i" (for some versions of df) will tell you about the latter.


<| Post or View Comments |>