GTDB-Tk, reference data, and job queues: leave jobs queued for this competitive cluster group!

usegalaxy.eu support
,
1

Hi, I have a GTDB-Tk classify_wf job that has been stuck in “queued” state
(never transitioned to “running”) for over 73 hours.

Job ID: 4838ba20a6d86765aad1b932f8f80dd1
Tool: toolshed.g2.bx.psu.edu/repos/iuc/gtdbtk_classify_wf/gtdbtk_classify_wf/2.7.2+galaxy0
Database: full_database_release_226_downloaded_2026-02-25
Submitted: 2026-08-01 00:16 UTC
Current state: queued (still, as of 2026-08-03)
Username: horikini

Input is a single history dataset collection of 1,263 bins (draft genomes)
produced by a MetaBAT2 binning run on a 75-sample metagenome co-assembly.

Checking the job via the API, external_id, handler, and job_runner_name are
all still null, suggesting it hasn’t been dispatched to a compute
destination at all yet. No error messages or job_messages are present.

Could someone take a look at whether this is expected queue depth for this
tool/destination right now, or whether something is blocking scheduling
specifically for this job? Happy to share more details if useful.

Thanks!

2

Welcome @horikini

Hopefully we can help! Yes, the tool does appear to be processing as expected UseGalaxy.eu → How to see the UseGalaxy.eu job queue statistics - #2 by jennaj

Updated Homepage

The view on the server homepage changed a bit recently, so this is how the same landmarks are now organized:

2026_usegalaxy-eu-usage-statistics
2026_usegalaxy-eu-usage-statistics1998×910 159 KB

GTDB-Tk status

I see about 120 queued jobs right now (seems to range between 110-140 recently), and the server is processing through about 4 of these jobs concurrently at any particular time.

gtdb-tk-queued
gtdb-tk-queued1186×952 148 KB

gtdb-tk-running
gtdb-tk-running2088×918 192 KB

Reference data, node resources, and combined impact on throughput

The reference data is extremely large (as I am sure you know!) and the 4 dedicated nodes are given significant working memory resources as compared to most if not all other tools. Leaving your job(s) queued will be important to keep them competitive for a slot in the processing!

More discussion in these topics have similar advice to this. gtdbtk_classify_wf

And, if you are looking for a workflow, these are our HTP versions from the IWC!

Did this help to explain what is going on and to know what to do? Follow up questions are welcome. :slight_smile:

3

Thanks for the explanation, that all makes sense!

Update: after ~169 hours in queue, the job finally got a compute slot —
but it failed immediately (exit code 2) with:

usage: gtdbtk
{de_novo_wf,classify_wf,identify,align,infer,classify,root,decorate,infer_ranks,ani_rep,test,trim_msa,remove_labels,convert_to_itol,convert_to_species,export_msa,check_install} …
gtdbtk: error: unrecognized arguments: --skip_ani_screen

It looks like the tool wrapper (gtdbtk_classify_wf/2.7.2+galaxy0) is
passing --skip_ani_screen as a default argument, but the installed
GTDB-Tk CLI binary doesn’t recognize that flag. This seems like a
version mismatch between the wrapper and the underlying GTDB-Tk
installation, not something caused by our inputs/parameters.

Job ID: 4838ba20a6d86765aad1b932f8f80dd1

Since this looks like a deterministic argument-parsing bug rather than
a transient issue, I wanted to flag it rather than just resubmit (which
I understand would just fail the same way and lose queue position for
no reason). Is this a known issue, and is there a fix in progress or a
workaround?

Thanks again for your help!

4

Hi @horikini Oh I’m so sorry, I thought this was corrected already but it appears to be still pending.

Let’s close this topic out and redirect over to the single active tracking topic for this! :hammer_and_wrench: