There were a number of bad workunits accidentally created around 13:00 - 14:00 UTC on 21 May. Examples:

WU 20154512
WU 20154529

They are timing out, and being resent. Although I'm pretty well acquainted with the tricksy ways of BOINC, I'm finding them hard to cope with. All the file downloads go into persistent 'transient HTTP error' - but it's not transient.

One successful way is to:

Wait until GPUGrid is idle (all previous tasks reported)
Stop BOINC
Edit client_state.xml
Change https:// to http:// for the affected download files only
Save file
Restart BOINC

but be very careful when editing that file - use text mode only.

I'll try some other ways when the machine runs dry again - but downloading the files via a browser didn't work for me this time.

We seem to have passed the bad batch, but I've got a fair few to deal with - and more will appear as people try to abort them, or in five days time when they timeout again.

I had like 10 of them in a row just hanging out and the system failed over the the backup project. I just nuked em all and it downloaded new work

---

Not sure how to uniquely identify the defective WUs. But I had dozens sitting in my Transfer list this morning with Project backoffs of 3 to 5 hours. Aborting them also required a reboot to get more WUs to DL and many of those failed to DL. For me GG is going idle.

I think it only needs a BOINC restart to clean them up, rather than a reboot - but I agree, it takes more than just a simple abort.

The trouble with aborting / nuking them is that they'll turn up again, like a bad penny. They'll each hang around until they reach their eighth error - which could be another 30 days away.

That's why I started this thread in the server area - I hoped I would attract advanced, skilled, users who knew how to edit files safely and efficiently, and help to get these blighters out of the way for good.

Can't the entire batch of bad pennies be extirpated from the server side???

Kicking the can down the road is only going to make this worse.

That's the other reason for posting in the server area - I was hoping Toni would notice and come up with a Cunning Plan.

Take a look at host 508381. Reported the last working task at 26 May 2020 | 16:11:12, got three new ones at 26 May 2020 | 16:13:00. Takes less than two minutes to shut down, edit the file, and start again, once you've got the hang of it. Another one bites the dust.

Wait until GPUGrid is idle (all previous tasks reported)
Stop BOINC
Edit client_state.xml
Change https:// to http:// for the affected download files only
Save file
Restart BOINC

but be very careful when editing that file - use text mode only.

I'm not sure that the task generated by a "repaired" task would come using https, so we may do it 10 times.
(I've aborted the transfer of these tasks, then restarted the BOINC manager, as it thinks that "some downloads are stalled". It refers to the ones I've aborted.)

I'm not sure that the task generated by a "repaired" task would come using https, so we may do it 10 times.

It probably doesn't, but I'm less worried about that. It downloads, it computes, it returns results, and it validates - that's the object of the exercise.

Check the examples I posted in the opening post - they won't be troubling us any more. But yours will be coming back, unless cancelled.

I tried to update the urls in the database so hopefully reissued results will have the correct url. thanks.

Also, for curiosity, the reason of the problem is that in some place the non-https gpugrid.org was used. Our certificate covered several domains but not that one.

Also, for curiosity, the reason of the problem is that in some place the non-https gpugrid.org was used. Our certificate covered several domains but not that one.

Ah, thanks. If any do leak out (let's hope not), I'll try using that as a fix, and report back.