Hey everyone! I'm struggling to get <#CE9MS66BS> v...
# aws-megatests
d
Hey everyone! I'm struggling to get #CE9MS66BS v5.5.0 AWS full test running. Any AWS/Fusion magicians around? 🙏 Tasks fails with exit 175 or 174. In both cases the task doesn't seem to be running at all. From the
.fusion.log
of a task that exited 175:
Copy code
22:18:06.266  configuration
22:18:06.346  FusionFS mounted at /fusion
22:18:06.85   .fusion/tmp/criu.kdat + .criu.move_mount_set_group.* probes
22:18:06.85   .fusion/dump/dump_metadata  (Insert entry)
22:18:06.953  FUSE server shutdown
The workdir has no
.exitcode
, no `.command.out`/`.command.err` and no partial outputs, so it's like
.command.sh
never executed. The module is a bioawk script that convert assembly depth format: github.com/nf-core/mag/blob/…/main.nf. Initially the module uncompressed the file inplace and then ran a for loop for every column. I changed that to pipe the script directly on
gzip -cd
and write the output file in one go to make it lighter / faster, but that did work either. Strangest part is that it's consistent for short-read assemblies while long-read ones finish fine, and both routes are identical, same module, same container, only depth file changes.
👀 1
r
Does it only fail here and works on your local cluster?
d
Yes, CI works. And also a run in my HPC too (not exactly with the same data, but real data, no mock datasets).
r
can you check if it works on your end with the exact same data?
d
Ok, I'll do that
r
This run also had 9 spot reclamations that were saved so maybe fusion couldn't rescue the last one, but just want to make sure we know the data works
d
Ok, I'll confirm as soon as I have that process finished at least
r
I had resubmitted it on a hunch on the on-demand CE to avoid more spot reclamations and this looks promising. It stil has a few failures, since they have errostrategy ignore, is this expected?
d
Hi again! The resubmit failed on CONVERT_DEPTHS too, same as before. The run on my HPC still doesn't finish but is running the last binning jobs (some of them retried by time). Regarding CONVERT_DEPTHS, all jobs finished successfully on first try with basically zero footprint (<=2s runtime, <30MB RAM usage). Very strange...
r
thanks for confirming. I'll take another look today
🙏 1
d
It finished now, here are the report and trace in case it is useful. Let me know if you need something else.
I tried again by replacing the container of the process for a new one build using wave, but it failed again on the same process: cloud.seqera.io/orgs/…/tasks I'm completely lost at this 🫠
Hey @Rike Hanssen, sorry to insist, but I wasn't able to figure out myself. Did you have time to look into this? I've been thinking to change the bioawk script for something else, but we already released v5.5.0 and still don't have the megatest results in the website.
r
d
Not yet, he isn't available right now
j
@Rike Hanssen I have a spare 2 minutes, do you mean duplicate the exisitng non-fusion one I tried, but add a chunky number here:
image.png
r
yep
j
Ok, any guide of what I should set?
Like what is the default?
Baring in my the failure I posted where you should suggested this was a failure on just FastQC 😅