Lsst_sims installation failed in ubuntu 16.04


I was trying to install lsst_sims in a Docker container using base image ubuntu 16.04. I keep getting error for [ 73/100 ] daf_persistence 16.0-3-g3806c63+7 … It seems like the installation stopped because the tests failed.

Can someone help me with this? I really appreciate it!

Weixiang Yu

Below is the full error message:
[ 73/100 ] daf_persistence 16.0-3-g3806c63+7 …

***** error: from /root/stack/miniconda3-4.5.4-fcd27eb/EupsBuildDir/Linux64/daf_persistence-16.0-3-g3806c63+7/build.log:

Running 1 test case…

*** No errors detected
Segmentation fault

Running 1 test case…

*** No errors detected
Segmentation fault
The following tests failed:
3 tests failed
scons: *** [checkTestStatus] Error 1
scons: building terminated because of errors.

+ exit -4
eups distrib: Failed to build daf_persistence-16.0-3-g3806c63+7.eupspkg: Command:
source “/root/eups/2.1.4/bin/”; export EUPS_PATH="/root/stack/miniconda3-4.5.4-fcd27eb"; (/root/stack/miniconda3-4.5.4-fcd27eb/EupsBuildDir/Linux64/daf_persistence-16.0-3-g3806c63+7/ >> /root/stack/miniconda3-4.5.4-fcd27eb/EupsBuildDir/Linux64/daf_persistence-16.0-3-g3806c63+7/build.log 2>&1 4>/root/stack/miniconda3-4.5.4-fcd27eb/EupsBuildDir/Linux64/daf_persistence-16.0-3-g3806c63+7/build.msg
exited with code 252

On the off chance that it will contain more information, do you mind posting this file:

Thanks for the quick response. @danielsf I am attaching the build.log file here. build.log (785.3 KB)

@swinbank @timj This looks like the same daf_persistence failure John had circa August 27. What was the resolution of that? Perusing Slack, it looks like the resolution was “we don’t know what is happening, but we don’t need the offending test, anyway, so we will just remove it from daf_persistence.” Is that accurate (in which case, @ywx649999311 I will need to issue a new version of lsst_sims).

I think you are running into this bug. We don’t have a fix for it, other than a plan to remove the code. One option is to seed your sims build by using the binaries or start with a docker container (although using ubuntu rather than CentOS7 might be problematic).

1 Like

@danielsf @timj. I am not actually in a rush. I already have a working docker container, and i just want to make some updates. Are you expecting a new version of lsst_sims coming out soon?

@ywx649999311 It sounds like issuing a new version of lsst_sims won’t do any good until the issue in the underlying Data Management software that Tim mentioned gets fixed.

What is it that you want to use lsst_sims for (for example: are you just using MAF?) It is possible that you don’t actually need to install the parts that depend on daf_persistence.

I only need MAF. Is there any work around? Can I just do something like ‘eups distrib install maf’ instead of using ‘eups distrib install lsst_sims -t sim’ to instal the who thing?


eups distrib install sims_maf -t sims

would just get you MAF. However, I just remembered that MAF has metrics that involve sky coverage, which involves mapping (RA, Dec) to position on the LSST focal plane, which involves daf_persistence. Sorry to get your hopes up.

1 Like

Dear All,

I seem to be running in tot he same problem on CentOS 7 with devtoolset-6.
I post a few more details below and attach the build.log.
Interestingly I also tried to run the two programs standalone in the debugger successfully without a crash!

It would be great if we could find a solution.

build.log (1.0 MB)

***** error: from /unix/atlas4/akorn/LSST/CATSIM/stack/miniconda3-4.5.4-fcd27eb/EupsBuildDir/Linux64/daf_persistence-16.0-3-g3806c63+7/build.log: warning: No data was collected. (no-data-collected)
Global pytest run completed successfully
Failed test output:

Running 1 test case…

*** No errors detected

Running 1 test case…

*** No errors detected
The following tests failed:
2 tests failed
scons: *** [checkTestStatus] Error 1
scons: building terminated because of errors.

  • exit -4
    eups distrib: Failed to build daf_persistence-16.0-3-g3806c63+7.eupspkg: Command:
    source “/unix/atlas4/akorn/LSST/CATSIM/eups/2.1.4/bin/”; export EUPS_PATH="/unix/atlas4/akorn/LSST/CATSIM/stack/miniconda3-4.5.4-fcd27eb"; (/unix/atlas4/akorn/LSST/CATSIM/stack/miniconda3-4.5.4-fcd27eb/EupsBuildDir/Linux64/daf_persistence-16.0-3-g3806c63+7/ >> /unix/atlas4/akorn/LSST/CATSIM/stack/miniconda3-4.5.4-fcd27eb/EupsBuildDir/Linux64/daf_persistence-16.0-3-g3806c63+7/build.log 2>&1 4>/unix/atlas4/akorn/LSST/CATSIM/stack/miniconda3-4.5.4-fcd27eb/EupsBuildDir/Linux64/daf_persistence-16.0-3-g3806c63+7/build.msg
    exited with code 252

It seems the bug still hasn’t been solved. I cannot install sims_catUtils because of this.

1 Like

As a workaround, I’m trying to use the Docker image (as per, but it doesn’t include the sims package (I need sims_catUtils and sims_photUtils). So I’m trying to install them with
eups distrib install -t 2.9.0.sims sims_catUtils

but I get
“Product <…> not found in any package repository.”

If I do eups distrib list sims_catUtils I get:
sims_catUtils Linux64 2.5.1.sims+1
sims_catUtils Linux64 2.5.1.sims+2
sims_catUtils Linux64 2.5.1.sims+3
sims_catUtils Linux64 2.8.0.sims+2
sims_catUtils Linux64 2.9.0.sims

I’ve already spent ridiculous amount of time on this and I’d appreciate some help.


For this last problem, I think you want eups distrib install sims_catUtils 2.9.0.sims, without the -t. (It’s a version, not a tag.)

For the segmentation fault, I believe we think we have solved this on master as of the end of October. I don’t know what sims builds have been done since then, but any build after that date should not exhibit the same problem.

(If you’re building daf_persistence-16.0-3-g3806c63+7, that’s the old July version, not something more recent.)

As of early this year, we have been building weekly sims releases. Is there any reason not to install one of those?

OK, the -t flag was the problem (duh!), but I hit the same bug again (as described above) while running eups distrib install sims_catUtils 2.9.0.sims.

Why not a newer version? Because I don’t see it as available inside the Docker container (or I don’t understand something…)

However, it seems that I found a different workaround (I don’t need to use the sims package directly anymore) so I will not pursue this any further.