Another one to add to the list. This one is "too late"
0003468_148
https://www.worldcommunitygrid.org/contribution/workunit/737134676

Well, that might be a bit of an overstatement. So far, it's a bit of a light drizzle rather than a flowing stream...

Ralf

Agreed!
I’ve hit my project limits for ARP1, which is the first time this has happened (or got anywhere near) in months. Let’s hope this is not just a one-off!
Cheers,
Mark

A remarkable workunit, I found:

The task with suffix _1 below was aborted 4 days after being distributed, after reaching 2 checkpoints, reason: "no longer usable".
The task with suffix _2 was distributed within the original deadlines (2025-07-09T16:50) of the tasks with suffixes _0 and _1.

workunit 738775281

ARP1_0014328_148_0  Linux Fedora  P. Validation   2025-07-03T16:50:27  2025-07-04T23:32:45  7.74/7.80  683.3/0.0
ARP1_0014328_148_1  Linux Ubuntu  Server Aborted  2025-07-03T16:50:32  2025-07-07T17:34:05  2.62/2.63    0.0/0.0
ARP1_0014328_148_2  Linux Ubuntu  In Progress     2025-07-09T05:19:12  2025-07-12T05:19:12  0.00/0.00    0.0/0.0

Details: ----------------------------------------------------------------------------------------------------------------

ARP1_0014328_148_0  Linux Fedora  P. Validation   2025-07-03T16:50:27  2025-07-04T23:32:45  7.74/7.80  683.3/0.0
	Sent Time: 2025-07-03T16:50:27+0000
	Due Time:  2025-07-09T16:50:27+0000
	Returned:  2025-07-04T23:32:45+0000
	Logfile:
	<core_client_version>8.0.2</core_client_version>
	<stderr_txt>
	INFO: Initializing
	INFO: No state to restore.  Start from the beginning.
	Starting WRFMain
	[18:32:27] INFO: Checkpoint taken at 2019-04-23_06:00:00
	[19:41:09] INFO: Checkpoint taken at 2019-04-23_12:00:00
	[20:38:35] INFO: Checkpoint taken at 2019-04-23_18:00:00
	[21:21:44] INFO: Checkpoint taken at 2019-04-24_00:00:00
	[22:23:34] INFO: Checkpoint taken at 2019-04-24_06:00:00
	[23:38:35] INFO: Checkpoint taken at 2019-04-24_12:00:00
	[00:39:19] INFO: Checkpoint taken at 2019-04-24_18:00:00
	[01:25:19] INFO: Checkpoint taken at 2019-04-25_00:00:00
	INFO: Simulation complete compressing output.
	01:26:30 (685683): called boinc_finish(0)
	
	</stderr_txt>
ARP1_0014328_148_1  Linux Ubuntu  Server Aborted  2025-07-03T16:50:32  2025-07-07T17:34:05  2.62/2.63    0.0/0.0
	Sent Time: 2025-07-03T16:50:32+0000
	Due Time:  2025-07-09T16:50:32+0000
	Returned:  2025-07-07T17:34:05+0000
	Logfile:
	<core_client_version>7.16.6</core_client_version>
	<message>
	aborted by project - no longer usable</message>
	<stderr_txt>
	INFO: Initializing
	INFO: No state to restore.  Start from the beginning.
	Starting WRFMain
	[04:40:23] INFO: Checkpoint taken at 2019-04-23_06:00:00
	INFO: Initializing
	Starting WRFMain
	[03:20:58] INFO: Checkpoint taken at 2019-04-23_12:00:00
	
	</stderr_txt>

Adri

Using the job log is a reasonable suggestion except for WUs like those recent Darwin ones that couldn't achieve validation. They'd be in the job log because the client thinks they are "success" tasks...

The best way to track stuck units would have been for folks to always announce problem tasks; we have seen some of that both in the [distant] past and recently, but I suspect that a lot of tasks have either been "lost" by the system or failed without anyone mentioning them here (often because the user is in "fire and forget" mode and never checks!). We only know about the Darwin issue because Unixchick has been flagging up tasks with validation issues, and I rather suspect there are [many?] more we don't know about!

As for whether the whole thing is an exercise in futility, that might depend on how many of the users who handle (say) 100+ ARP1 tasks a day might provide data. (My average of 15 or so returns a day would be hardly a drop in the ocean, but I would always report any WU that got stuck!)

Cheers - Al.