forked from lix-project/lix
9dbfe242e3
seconds without producing output on stdout or stderr (NIX-65). This timeout can be specified using the `--max-silent-time' option or the `build-max-silent-time' configuration setting. The default is infinity (0). * Fix a tricky race condition: if we kill the build user before the child has done its setuid() to the build user uid, then it won't be killed, and we'll potentially lock up in pid.wait(). So also send a conventional kill to the child.
156 lines
6.2 KiB
Plaintext
156 lines
6.2 KiB
Plaintext
### Option `gc-keep-outputs'
|
|
#
|
|
# If `true', the garbage collector will keep the outputs of
|
|
# non-garbage derivations. If `false' (default), outputs will be
|
|
# deleted unless they are GC roots themselves (or reachable from other
|
|
# roots).
|
|
#
|
|
# In general, outputs must be registered as roots separately.
|
|
# However, even if the output of a derivation is registered as a root,
|
|
# the collector will still delete store paths that are used only at
|
|
# build time (e.g., the C compiler, or source tarballs downloaded from
|
|
# the network). To prevent it from doing so, set this option to
|
|
# `true'.
|
|
#gc-keep-outputs = false
|
|
|
|
|
|
### Option `gc-keep-derivations'
|
|
#
|
|
# If `true' (default), the garbage collector will keep the derivations
|
|
# from which non-garbage store paths were built. If `false', they
|
|
# will be deleted unless explicitly registered as a root (or reachable
|
|
# from other roots).
|
|
#
|
|
# Keeping derivation around is useful for querying and traceability
|
|
# (e.g., it allows you to ask with what dependencies or options a
|
|
# store path was built), so by default this option is on. Turn it off
|
|
# to safe a bit of disk space (or a lot if `gc-keep-outputs' is also
|
|
# turned on).
|
|
#gc-keep-derivations = true
|
|
|
|
|
|
### Option `gc-reserved-space'
|
|
#
|
|
# This option specifies how much space should be reserved in normal
|
|
# use so that the garbage collector can run succesfully. Since the
|
|
# garbage collector must perform Berkeley DB transactions, it needs
|
|
# some disk space for itself. However, when the disk is full, this
|
|
# space is not available, so the collector would not be able to run
|
|
# precisely when it is most needed.
|
|
#
|
|
# For this reason, when Nix is run, it allocates a file
|
|
# /nix/var/nix/db/reserved of the size specified by this option. When
|
|
# the garbage collector is run, this file is deleted before the
|
|
# Berkeley DB environment is opened. This should give it enough room
|
|
# to proceed.
|
|
#
|
|
# The default is "1048576" (1 MiB).
|
|
#gc-reserved-space = 1048576
|
|
|
|
|
|
### Option `env-keep-derivations'
|
|
#
|
|
# If `false' (default), derivations are not stored in Nix user
|
|
# environments. That is, the derivation any build-time-only
|
|
# dependencies may be garbage-collected.
|
|
#
|
|
# If `true', when you add a Nix derivation to a user environment, the
|
|
# path of the derivation is stored in the user environment. Thus, the
|
|
# derivation will not be garbage-collected until the user environment
|
|
# generation is deleted (`nix-env --delete-generations'). To prevent
|
|
# build-time-only dependencies from being collected, you should also
|
|
# turn on `gc-keep-outputs'.
|
|
#
|
|
# The difference between this option and `gc-keep-derivations' is that
|
|
# this one is `sticky': it applies to any user environment created
|
|
# while this option was enabled, while `gc-keep-derivations' only
|
|
# applies at the moment the garbage collector is run.
|
|
#env-keep-derivations = false
|
|
|
|
|
|
### Option `build-max-jobs'
|
|
#
|
|
# This option defines the maximum number of jobs that Nix will try to
|
|
# build in parallel. The default is 1. You should generally set it
|
|
# to the number of CPUs in your system (e.g., 2 on a Athlon 64 X2).
|
|
# It can be overriden using the `--max-jobs' / `-j' command line
|
|
# switch.
|
|
#build-max-jobs = 1
|
|
|
|
|
|
### Option `build-max-silent-time'
|
|
#
|
|
# This option defines the maximum number of seconds that builder can
|
|
# go without producing any data on standard output or standard error.
|
|
# This is useful (for instance in a automated build system) to catch
|
|
# builds that are stuck in an infinite loop, or to catch remote builds
|
|
# that are hanging due to network problems. It can be overriden using
|
|
# the `--max-silent-time' command line switch.
|
|
#
|
|
# The value 0 means that there is no timeout. This is also the
|
|
# default.
|
|
#
|
|
# Example:
|
|
# build-max-silent-time = 600 # = 10 minutes
|
|
#build-max-silent-time = 0
|
|
|
|
|
|
### Option `build-users-group'
|
|
#
|
|
# This options specifies the Unix group containing the Nix build user
|
|
# accounts. In multi-user Nix installations, builds should not
|
|
# be performed by the Nix account since that would allow users to
|
|
# arbitrarily modify the Nix store and database by supplying specially
|
|
# crafted builders; and they cannot be performed by the calling user
|
|
# since that would allow him/her to influence the build result.
|
|
#
|
|
# Therefore, if this option is non-empty and specifies a valid group,
|
|
# builds will be performed under the user accounts that are a member
|
|
# of the group specified here (as listed in /etc/group). Those user
|
|
# accounts should not be used for any other purpose!
|
|
#
|
|
# Nix will never run two builds under the same user account at the
|
|
# same time. This is to prevent an obvious security hole: a malicious
|
|
# user writing a Nix expression that modifies the build result of a
|
|
# legitimate Nix expression being built by another user. Therefore it
|
|
# is good to have as many Nix build user accounts as you can spare.
|
|
# (Remember: uids are cheap.)
|
|
#
|
|
# The build users should have permission to create files in the Nix
|
|
# store, but not delete them. Therefore, /nix/store should be owned
|
|
# by the Nix account, its group should be the group specified here,
|
|
# and its mode should be 1775.
|
|
#
|
|
# If the build users group is empty, builds will be performed under
|
|
# the uid of the Nix process (that is, the uid of the caller if
|
|
# $NIX_REMOTE is empty, the uid under which the Nix daemon runs if
|
|
# $NIX_REMOTE is `daemon', or the uid that owns the setuid nix-worker
|
|
# program if $NIX_REMOTE is `slave'). Obviously, this should not be
|
|
# used in multi-user settings with untrusted users.
|
|
#
|
|
# The default is empty.
|
|
#
|
|
# Example:
|
|
# build-users-group = nix-builders
|
|
#build-users-group =
|
|
|
|
|
|
### Option `system'
|
|
#
|
|
# This option specifies the canonical Nix system name of the current
|
|
# installation, such as `i686-linux' or `powerpc-darwin'. Nix can
|
|
# only build derivations whose `system' attribute equals the value
|
|
# specified here. In general, it never makes sense to modify this
|
|
# value from its default, since you can use it to `lie' about the
|
|
# platform you are building on (e.g., perform a Mac OS build on a
|
|
# Linux machine; the result would obviously be wrong). It only makes
|
|
# sense if the Nix binaries can run on multiple platforms, e.g.,
|
|
# `universal binaries' that run on `powerpc-darwin' and `i686-darwin'.
|
|
#
|
|
# It defaults to the canonical Nix system name detected by `configure'
|
|
# at build time.
|
|
#
|
|
# Example:
|
|
# system = i686-darwin
|
|
#system =
|