28c0dd9148
Fixes #9166 This is intended to reduce errors related to lock timeouts by making the following changes: * Improves error reporting when acquiring a lock fails (addressing #9166) - there is no longer an attempt to release the lock if an acquire fails * By default locks taken on individual packages no longer have a timeout. This allows multiple spack instances to install overlapping dependency DAGs. For debugging purposes, a timeout can be added by setting 'package_lock_timeout' in config.yaml * Reduces the polling frequency when trying to acquire a lock, to reduce impact in the case where NFS is overtaxed. A simple adaptive strategy is implemented, which starts with a polling interval of .1 seconds and quickly increases to .5 seconds (originally it would poll up to 10^5 times per second). A test is added to check the polling interval generation logic. * The timeout for Spack's whole-database lock (e.g. for managing information about installed packages) is increased from 60s to 120s * Users can configure the whole-database lock timeout using the 'db_lock_timout' setting in config.yaml Generally, Spack locks (those created using spack.llnl.util.lock.Lock) now have no timeout by default This does not address implementations of NFS that do not support file locking, or detect cases where services that may be required (nfslock/statd) aren't running. Users may want to be able to more-aggressively release locks when they know they are the only one using their Spack instance, and they encounter lock errors after a crash (e.g. a remote terminal disconnect mentioned in #8915).
110 lines
3.8 KiB
YAML
110 lines
3.8 KiB
YAML
# -------------------------------------------------------------------------
|
|
# This is the default spack configuration file.
|
|
#
|
|
# Settings here are versioned with Spack and are intended to provide
|
|
# sensible defaults out of the box. Spack maintainers should edit this
|
|
# file to keep it current.
|
|
#
|
|
# Users can override these settings by editing the following files.
|
|
#
|
|
# Per-spack-instance settings (overrides defaults):
|
|
# $SPACK_ROOT/etc/spack/config.yaml
|
|
#
|
|
# Per-user settings (overrides default and site settings):
|
|
# ~/.spack/config.yaml
|
|
# -------------------------------------------------------------------------
|
|
config:
|
|
# This is the path to the root of the Spack install tree.
|
|
# You can use $spack here to refer to the root of the spack instance.
|
|
install_tree: $spack/opt/spack
|
|
|
|
|
|
# Locations where templates should be found
|
|
template_dirs:
|
|
- $spack/share/spack/templates
|
|
|
|
|
|
# default directory layout
|
|
directory_layout: "${ARCHITECTURE}/${COMPILERNAME}-${COMPILERVER}/${PACKAGE}-${VERSION}-${HASH}"
|
|
|
|
|
|
# Locations where different types of modules should be installed.
|
|
module_roots:
|
|
tcl: $spack/share/spack/modules
|
|
lmod: $spack/share/spack/lmod
|
|
dotkit: $spack/share/spack/dotkit
|
|
|
|
|
|
# Temporary locations Spack can try to use for builds.
|
|
#
|
|
# Spack will use the first one it finds that exists and is writable.
|
|
# You can use $tempdir to refer to the system default temp directory
|
|
# (as returned by tempfile.gettempdir()).
|
|
#
|
|
# A value of $spack/var/spack/stage indicates that Spack should run
|
|
# builds directly inside its install directory without staging them in
|
|
# temporary space.
|
|
#
|
|
# The build stage can be purged with `spack clean --stage`.
|
|
build_stage:
|
|
- $tempdir
|
|
- /nfs/tmp2/$user
|
|
- $spack/var/spack/stage
|
|
|
|
|
|
# Cache directory already downloaded source tarballs and archived
|
|
# repositories. This can be purged with `spack clean --downloads`.
|
|
source_cache: $spack/var/spack/cache
|
|
|
|
|
|
# Cache directory for miscellaneous files, like the package index.
|
|
# This can be purged with `spack clean --misc-cache`
|
|
misc_cache: ~/.spack/cache
|
|
|
|
|
|
# If this is false, tools like curl that use SSL will not verify
|
|
# certifiates. (e.g., curl will use use the -k option)
|
|
verify_ssl: true
|
|
|
|
|
|
# If set to true, Spack will always check checksums after downloading
|
|
# archives. If false, Spack skips the checksum step.
|
|
checksum: true
|
|
|
|
|
|
# If set to true, `spack install` and friends will NOT clean
|
|
# potentially harmful variables from the build environment. Use wisely.
|
|
dirty: false
|
|
|
|
|
|
# When set to true, concurrent instances of Spack will use locks to
|
|
# avoid modifying the install tree, database file, etc. If false, Spack
|
|
# will disable all locking, but you must NOT run concurrent instances
|
|
# of Spack. For filesystems that don't support locking, you should set
|
|
# this to false and run one Spack at a time, but otherwise we recommend
|
|
# enabling locks.
|
|
locks: true
|
|
|
|
|
|
# The default number of jobs to use when running `make` in parallel.
|
|
# If set to 4, for example, `spack install` will run `make -j4`.
|
|
# If not set, all available cores are used by default.
|
|
# build_jobs: 4
|
|
|
|
|
|
# If set to true, spack will use ccache to cache c compiles.
|
|
ccache: false
|
|
|
|
# How long to wait to lock the Spack installation database. This lock is used
|
|
# when spack needs to manage its own package metadata and all operations are
|
|
# expected to complete within the default time limit. The timeout should
|
|
# therefore generally be left untouched.
|
|
db_lock_timeout: 120
|
|
|
|
# How long to wait when attempting to modify a package (e.g. to install it).
|
|
# This value should typically be 'null' (never time out) unless the Spack
|
|
# instance only ever has a single user at a time, and only if the user
|
|
# anticipates that a significant delay indicates that the lock attempt will
|
|
# never succeed.
|
|
package_lock_timeout: null
|