Hi, following on from a previous issue where someone had problems with aws
locating the libz shared object.
We have encountered similar - and have now narrowed it down to the underlying docker image for the tasks.
So our minimal task is either based
FROM quay.io/biocontainers/mulled-v2-4dde50190ae599f2bb2027cb2c8763ea00fb5084:4163e62e1daead7b7ea0228baece715bec295c22-0
or
FROM docker.io/continuumio/miniconda3:23.10.0-1
and consists of (as per an example launch from seqera)
CMD ["bash","-o","pipefail","-c","trap \"{ ret=$?; /opt2/awscliv2/bin/aws s3 cp --only-show-errors .command.log s3://stub_run/work/.command.log||true; exit $ret; }\" EXIT; /opt2/awscliv2/bin/aws s3 cp --only-show-errors s3://stub_run/work/.command.run - | bash 2>&1 | tee .command.log"]
Where mulled
in used - the task fails with a libz.so error. Where miniconda
is used - the tasks succeeds (well - the aws
bits run anyhow).
Now I realise there is possibly a massive difference in libraries between the two images - but I thought the point of mapping in the underlying aws
v2 cli implementation from the base Batch machine was that it provides its own dependencies in /opt2/aws-cli
(in our case).
Are there some hidden extra dependencies perhaps?