How do I avoid a non-alphanumeric "user" container property when submitting AWS Batch jobs through Nextflow?

Viewed 44

I'm trying to run a Nextflow workflow with AWS Batch, but all my jobs fail with the following error:

The user value contains invalid characters. Enter a value that matches the pattern ^([a-z0-9_][a-z0-9_-]{0,30})$

In the container section of the job details page, the user value is $(id, which I'm assuming is the cause of this error. I think this is happening because in my nexflow.config file, I have the following line:

containerOptions = { workflow.containerEngine == "docker" ? '-u $(id -u):$(id -g)': null}

I believe this line is supposed to avoid having Docker run as root, though if I remove the line completely my jobs never get past the "Runnable" state in AWS Batch.

The full workflow I'm trying to run is a small test workflow from a course, and is on GitHub here: https://github.com/biocorecrg/SIB_course_nextflow_Nov_2021/tree/main/nextflow/test3

I'm running it with the command nextflow run test3.nf -with-docker -profile cloud.

1 Answers

The value for the container user would actually be: $(id -u):$(id -g) if it had been quoted:

containerOptions = { workflow.containerEngine == "docker" ? '-u "$(id -u):$(id -g)"': null}

But this is still problematic because the uid and gid values are never resolved. I also thought the containerOptions line could be removed. Because, there's no reason to provide a username using the biocorecrg/c4lwg-2018:latest (840603e6fa60) container AFAICT. I thought it was strange that your jobs never got past the "Runnable" state so I gave it a go and it actually completed successfully:

$ nextflow run test3.nf -with-docker -profile cloud
N E X T F L O W  ~  version 22.04.3
Launching `test3.nf` [clever_fermi] DSL2 - revision: 75319c0ead

BIOCORE@CRG - N F TESTPIPE  ~  version 1.0
=============================================
reads                           : /home/ec2-user/working/stackoverflow/72364414/SIB_course_nextflow_Nov_2021/nextflow/test3/../../testdata/*.fastq.gz
reference                       : /home/ec2-user/working/stackoverflow/72364414/SIB_course_nextflow_Nov_2021/nextflow/test3/../../testdata/chr19.fasta.gz
outdir                          : /home/ec2-user/working/stackoverflow/72364414/SIB_course_nextflow_Nov_2021/nextflow/test3

executor >  awsbatch (6)
[50/af2244] process > fastQC (B7_input_s_chr19.fastq.gz)      [100%] 2 of 2 ✔
[0e/c05d6c] process > bowtieIdx (chr19.fasta.gz)              [100%] 1 of 1 ✔
[70/a0b971] process > bowtieAln (B7_H3K4me1_s_chr19.fastq.gz) [100%] 2 of 2 ✔
[9d/a6562e] process > multiQC                                 [100%] 1 of 1 ✔

Done! Open the following report in your browser --> /home/ec2-user/working/stackoverflow/72364414/SIB_course_nextflow_Nov_2021/nextflow/test3/ouptut_multiQC/multiqc_report.html

Completed at: 25-May-2022 22:36:56
Duration    : 8m 22s
CPU hours   : 0.1
Succeeded   : 6

I was also able to run the workflow using the 'standard' profile (with and without setting the containerOptions directive) no problems. It was quite a bit faster too at 1m 40s. So if the AWS Batch jobs that are submitted don't progress past the "Runnable" state, then my guess is that the job queue might need to be reconfigured somehow. For example, the compute environment attached to the job queue might not have enough available resources to start the jobs.

Related