** Using WeBWorK **

Thanks for the message. I see the logs in the usual spot, yes. No messages about grades previous over the last 4 days.

I set the `debug_lti_grade_passback = 1` conf in `authen_LTI.conf`, and the refresh interval to 60 seconds. I do get some messages. There's a series of

• LTI Mass Update: Queueing grade update for all sets and users.

Any idea what exact mechanism the queueing takes on, and whether it logs to webwork2.log? With a 60 second timing, I would have expected more messages, and maybe some failures, if it wasn't working?

Ah, a nice simple fix -- thank you!

I ended up needing to run "npm ci" twice.  The first time was using Ubuntu 22.04's node package, which is still at version 12, and I got syntax errors.  I ended up installing the official node 18 binaries from nodejs.org and using those, but apparently I did that after I'd started the webwork2 service and didn't think to restart it.

Thanks again!

You need to restart the webwork2 app.  Run "sudo systemctl restart webwork2" for this.

What is happening is that you have run "npm ci" after starting the webwork2 app initially, and changed the static-assets.json file.  Since the server has already loaded the old version of that file (or failed to load it if you hadn't run "npm ci" before starting the server), any worker that has not been restarted since the app started will not get the correct minimized file names.  When you refresh the page in the browser you might get lucky and use a worker that has been restarted, or not.  If a worker that has been restarted is used, you get the correct link.  Otherwise it falls back to the original filename without the minimized hash.

When you restart the app, all workers are restarted and the issue will be fixed.

This is expected behavior.  It is tantamount to needing to restart apache2 prior to webwork 2.18.  In fact exactly the same behavior could be observed with webwork 2.17 in this scenario.

I just upgraded our WeBWorK server to 2.18 and I'm running into an interesting problem.  Sometimes, when a page is loaded, the links to the CSS files give me 404 errors since they're not pointing to the minified versions with the hashes in the filenames.  For example:

<link href="/webwork2_files/themes/math4-green/bootstrap.css" rel="stylesheet">

But after refreshing (sometimes several times), I finally get the correct link, e.g.,:

<link href="/webwork2_files/themes/math4-green/bootstrap.4be740be.min.css" rel="stylesheet">

I tried clearing my browser's cache, but that didn't help.  Any thoughts?

Thanks!

Logging in as admin, the Course Administration page shows links for dealing with courses.

Click on Delete Course or Archive Course and the default "select listing format" is shown as alphabetical and the courses are indeed listed alphabetically.

But click on Hide Courses and the default "select listing format" is still shown as alphabetical but the courses are listed by last login date. Need to click "refresh listing" to get them in alphabetical order.

You really shouldn't paste the code into knowl.xxxxxxxx.min.js.  Instead you should paste it into knowl.js.  Then run "npm ci" in the pg/htdocs directory.  That will generate a new knowl.xxxxxxxx.min.js file with the updated contents with a new xxxxxxxx hash.  Make sure to restart apache2 so that it loads the updated static-assets.json file.  This way your users will not need to do a hard refresh in their browsers to get the updated content.  If you change knowl.xxxxxxxx.js directly they will need to do that, or the browser will use the cached file.

In addition, by changing knowl.js and running "npm ci", the javascript is minimized.  This reduces the size of the file and saves bandwidth for your users.

Hi, I've got a little more info now on this issue.  I did a new test today.  I opened a test at 3:07:07, with a 3 minute time limit, and simply let the test stay open.  At around 3:12 -- right when the auto submit should take place -- I noticed that the icon in my browser tab looked like it started refreshing repeatedly.  Sure enough, in the server log, there are records of POST requests each second from 3:12:02 to 3:12:07 (at which time I logged out of WW, to thwart another crash).

From the last actual crash, the server log shows that there was an out-of-memory kill.

So it sounds a little like WeBWorK auto-submit is trying to submit over and over again.  Apologies if this is misleading or unhelpful info, but if I'm right, could you imagine any reason why that might be happening?  Thanks again!

Hello Everyone

This is my first post to the forum.  We run multiple instances of WW, one instance per member College, and each instance lives on a dedicated VM.  We're running WW 2.15 on RHEL8 and users access the server through a F5 load balancer, though with one server per site we aren't actually doing any load balancing with it.  The F5 just takes care of public-facing SSL and IP. 

The setup has been stable for some time, but we recently started seeing an error when using the file manager.  I can click on File Manager without issue, but clicking on anything in the file list, whether directory or file, generates this error:

WeBWorK error

An error occured while processing your request. For help, please send mail to this site's webmaster, including all of the following information as well as what what you were doing when the error occured.

Wed Sep 21 08:46:23 2022

Warning messages

Error messages

Internal apreq error

Call stack

The information below can help locate the source of the problem.

• in Apache2::Request::upload called at line 252 of /opt/webwork/webwork2/lib/WeBWorK.pm

The reason the students get this message is because they are refreshing the page after submitting the answer.

Most likely the student submits the answer, then it takes a long time, and then the student gets impatient and refreshes the page.  That is when they get this issue.

I am not sure what is causing the lag, but the message is not related.  Nor does it help in diagnosing the issue unfortunately.