Adri.

[Drifting towards the margins of "off topic" here, perhaps, but...]

I'll answer a couple of your questions by saying that the script keeps a catalogue of workunit names it has seen, assessed and either aborted or passed for execution. At the start of each pass through client_state it marks them as "not seen this time", and if it sees them again it marks them as "seen" but doesn't do anything else! At the end of the pass, any names not seen on that occasion get removed from the catalogue.[*1]

If the script gets shut down, it dumps the current state of that catalogue, which it will re-read the next time it starts up; again, that should stop repeated efforts to abort in the unlikely event that it has taken a long time to report the aborted task!

The script sleeps for 5 minutes between passes, so there's a fair chance that aborted units might've vanished already; as for the "urgent" tasks, they're unlikely to get priority over existing tasks on my systems as I only allow very small (<10) numbers of tasks for SCC1 (and MCM1, as it happens) at a time...

As for hacking on the logging module(s) to get UTC time, I probably could if I had the time to spare, but...

Cheers - Al.

P.S. [Definitely off topic :-)] I haven't even looked at puzzle creation again yet -- too much else going on at the moment :-)

[*1] All the techniques used for this script had already been employed for daemons I use to collect information on receptors and ligands for OPN1/G and SCC1, control parameters for MCM1 and task completion information for all WCG projects. The cataloguing technique described above is essential for the pre-run data collection scripts, as there's often a lot of files to check out and it should only be done once per task! The code of the daemons may not be optimal but it has a proven track record :-)

In an ultimate attempt to try to stop executing any tasks from faulty batches that error out straight away, resulting in an unreliable client, in the file app_config.xml I've tried setting <max_concurrent> for scc1 to -1. That worked! Now, any tasks from SCC1 aren't executing anymore, so that any tasks from faulty batches can get aborted (User Aborted) before they immediately start upon receipt.
Reason: as soon as you're reliable, you will have a better chance of receiving tasks from SCC1.

In the meantime, has anyone noticed that there aren't any new tasks from faulty batch 0004176 around anymore? The last ones I received were SCC1_0004176_MyoD1-C_56409_0 and SCC1_0004176_MyoD1-C_56530_0, received at 2023-06-09T14:00:39.

Something that I also noticed was that when you abort a faulty _0 task, two tasks are generated, one with a 6-day deadline and another with a 3-day deadline! See below.

 <1> * SCC1_0004165_MyoD1-C_4795_0  Fedora Linux  User Aborted  2023-06-10T09:35:42  2023-06-10T09:37:50
 <1>   SCC1_0004165_MyoD1-C_4795_1  Linuxmint     In Progress   2023-06-10T09:35:48  2023-06-16T09:35:48
 <1>   SCC1_0004165_MyoD1-C_4795_2  Linux Ubuntu  In Progress   2023-06-10T09:38:15  2023-06-13T09:38:15

Adri

I've not seen any additional SCC1_0004176 since about 24-hrs ago.

Unfortunately, (4) bad SCC1_0004174 's floated-in overnight and immediately error'd. One was across a brand new machine I just brought online -- hoping that box doesn't get put on the "bad list" that others previously noted.

I just logged an error on a 4174 task with 5 entries (4 errors and 1 in progress, replication 2) in results. That in progress guy is going to be disappointed,

@TigerLily,

Can we get an update on the defective SCC batches?

Any ETA for a fix?

Thanks,
AgrFan