I have a crop of GCW workunits that die at a client restart, usually after a reboot.

The problem is *nearly* replicable by using systemctl restart boinc.client.service. About one in ten survive this test.

Symptoms are that immediately on restart of the client the workunit finishes, uploads, and goes into the wait for validation, which it inevitable fails in due course.

This is a loss of credit to me for the crunching before the restart (though I do not expect credit where work fails, I do not expect restarting to trigger the "end of task" sequence prematurely). It also means (as with any invalid worK) the original wingman gets mixed feelings: they are first finisher, but the new wingman is not appointed till after the original wingman's task completes and they have no chance of being first.

This seems specific to llrGCW:

I also tried this with AP, a variety of other LLR tasks, and two different GFN n values. All of these survive the restart without problem.

At present I have only seen this on my Qubes / Xen machine, but will not have time to check out this behaviour on my "real" machines for a few days, and will update this thread by the weekend after I have done those tests. My hunch, without testing, is that this will turn out to be another Qubes-specific issue.

I would be glad of any immediate comments if this kind of issue has arisen before?

I did not see it before the server move, but was not trying to run llrGCW so I have no reason to suspect the migration.

R~~

GCW does not seem to have any huge memry requirements that might trigger this, but if there are significant differences with other LLR tasks please give me a heads up.


____________
My computers found:

9831*2^1441403+1 is a quadhectokilo prime prime, ie >400,000 digits ;)

252031090528237591 + 65521*149*23*19*17*13*11*7*5*3*2*n is prime for every n in { 0..20 } (an arithemtic progression of 21 primes)

Examples:

I restarted the client at about 1603 by the computer's clock while two llrGCW tasks were running, but without rebooting the virtual machine -- or the host ;).

this unit survived and carried on with about 43 mins elapsed. THis WU has survived several restarts.

whereas this one exited showing "success" as the outcome on the task's web page, but cannot conceivably validate with a run time of only about 35 mins

Here is the event log for this client start, showing the WU ending and being reported and showing the next one starting.

This is NOT just Xen, NOT just Qubes

I have just replicated this behaviour on a "real" computer running Linux as a real OS

That means the behaviour has been seen on two computers. running two different Debian derivatives, one running on "real metal" and one on a VM.

• Xen / Qubes / Debian 9 (VM)
  
• Linux Mint (Sarah) (real)
  

The Linux Mint machine has been used for some time on PG without displaying this behaviour on any other type of task, and the software is the same as always, other than regular updating from the OS repositories.

This is the first time the machine has ever downloaded a GCW task, and each of the first eight ended early (but with a "success" code) when the client was restated. The OS was NOT rebooted either time. The first 4 failed when the client was restarted after some 18 hours running, the second four when the client was restarted after only a very short run.

These tasks are listed here - if there are more than eight look for the oldest ones, reported between 1100 and 1200 UT on Nov 28.
____________
My computers found:

9831*2^1441403+1 is a quadhectokilo prime prime, ie >400,000 digits ;)

252031090528237591 + 65521*149*23*19*17*13*11*7*5*3*2*n is prime for every n in { 0..20 } (an arithemtic progression of 21 primes)