Seemingly stalled task (at 8.427 %)

Hi Peter,
I'm very happy to hear that everything is back to normal.  Thanks for setting out the steps you took.  I'll comment on a couple of things in case it might be helpful to you.  Your computers are hidden, which is absolutely fine - your choice, but it does make it impossible to investigate details about your hardware, your OS, and tasks that have been completed and returned.

When I first saw reference to boinccmd, my immediate reaction was that you must be running Linux without a GUI.  Later on in the event log snip, I see the Windows app mentioned (so you do have a perfectly serviceable GUI), so my question is, why do step 1?

If you want to see details of all things going on with tasks, the most convenient way is to use BOINC Manager (Advanced view).  I run Linux and do use boinccmd in control scripts I write for my hosts, but the Manager interface is so much easier to use when you want to browse and control individual machines.  My suggestion is to permanently switch to the advanced view and explore what is available to you in the various menu items.  To get lots of details about a particular task, you select the Tasks tab, select a task of interest by clicking on it, and then click 'properties' to get a nicely formatted popup showing all the details.

Do you mean Current CPU time?  That should always be > checkpoint CPU time unless you happen to be looking at the very instant the checkpoint is being written (when they would be roughly equal).  The greater the separation between the two, the more crunching time that is 'lost' if you stop BOINC and then restart from that checkpoint.

I presume you selected the task and clicked a button that was saying 'Resume' before you clicked it and as a result, the status of the task changed from 'Suspended' to, perhaps 'Waiting to run', or something like that?  Did you wait to see if this task would start when one of the running tasks finished?

I'm guessing you would do this (exit completely) if the 'Waiting to run' task didn't make any further progress after it actually was allowed to run?  It will continue 'waiting' until a running task finishes.  At that point, its status should change from 'Waiting' to 'Running' irrespective of whether or not it made any further progress.  Then, if you decided it really wasn't making further progress (this is where the 'properties' function I described above is very useful), it would be appropriate to stop BOINC completely, wait a bit, and then restart BOINC.

I have no first hand experience with lock files but here is my understanding.

On multi-core machines, it's important that two (or more) different instances of an app, running on different cores, aren't both trying to work on the same task.  Under normal conditions, when a task starts crunching, an individual 'slot directory' is created which is populated with everything needed (discrete copies or links) as appropriate.  All working and temporary files for this task (including the checkpoint file) will be created in this same directory.

To prevent any other instance of the app using this particular slot, a lock file is created which basically means the directory is in use.  A particular instance of the app 'knows' exactly which lockfile it 'owns'.  I don't fully understand how it all works, but even if you suspend a task so that a new task starts in an extra slot directory, and even if the whole machine is shut down and restarted, there can be an orderly taking up of partially completed tasks by single instances of the app once again.  Lock files are created and removed in such a way as to guarantee this (usually) :-).

There can be abnormal events (I don't know the details) where a partly completed task can be sitting in a slot with a lock file basically saying that this task is 'owned' but where there is actually no app instance that 'owns' it.  I think it is something like this that you were seeing.  In the BOINC directory, there is a sub-directory called 'slots' and in that are further subdirs called '0' '1' '2' .... as many as needed to hold all the working files for in-progress tasks.  When tasks are finished and reported, slots are cleared and reused or deleted if no longer needed.  If a slot contains a lock file when it shouldn't, then you'll have a problem giving messages like you were seeing.

From memory, I've seen (over many years) people talking about deleting lock files in slot directories as a solution.  I think this is needed when stopping and restarting BOINC doesn't clear the problem.  I also seem to recall that rebooting the machine has sometimes sorted things out.  If I'm reading your report correctly, this seems to have worked for you.

Since you spent a lot of time (very commendable with your short experience) in documenting what you observed and what you did), I thought the least I could do was try to interpret your report, both for your edification and for that of any one else interested in reading this far :-).