Next: Application Setup, Previous: Setting Up the Daemon, Up: Installation [Contents][Index]
guix-daemon
The guix-daemon
program implements all the functionality to
access the store. This includes launching build processes, running the
garbage collector, querying the availability of a build result, etc. It
is normally run as root
like this:
# guix-daemon --build-users-group=guixbuild
This daemon can also be started following the systemd “socket
activation” protocol (see make-systemd-constructor
in The GNU Shepherd Manual).
For details on how to set it up, see Setting Up the Daemon.
By default, guix-daemon
launches build processes under
different UIDs, taken from the build group specified with
--build-users-group. In addition, each build process is run in a
chroot environment that only contains the subset of the store that the
build process depends on, as specified by its derivation
(see derivation), plus a set of specific
system directories. By default, the latter contains /dev and
/dev/pts. Furthermore, on GNU/Linux, the build environment is a
container: in addition to having its own file system tree, it has
a separate mount name space, its own PID name space, network name space,
etc. This helps achieve reproducible builds (see Features).
When the daemon performs a build on behalf of the user, it creates a
build directory under /tmp or under the directory specified by
its TMPDIR
environment variable. This directory is shared with
the container for the duration of the build, though within the container,
the build tree is always called /tmp/guix-build-name.drv-0.
The build directory is automatically deleted upon completion, unless the build failed and the client specified --keep-failed (see --keep-failed).
The daemon listens for connections and spawns one sub-process for each session
started by a client (one of the guix
sub-commands). The
guix processes
command allows you to get an overview of the activity
on your system by viewing each of the active sessions and clients.
See Invoking guix processes
, for more information.
The following command-line options are supported:
--build-users-group=group
Take users from group to run build processes (see build users).
--no-substitutes
¶Do not use substitutes for build products. That is, always build things locally instead of allowing downloads of pre-built binaries (see Substitutes).
When the daemon runs with --no-substitutes, clients can still
explicitly enable substitution via the set-build-options
remote procedure call (see The Store).
--substitute-urls=urls
Consider urls the default whitespace-separated list of substitute
source URLs. When this option is omitted,
‘https://ci.guix.gnu.org https://bordeaux.guix.gnu.org
’ is used.
This means that substitutes may be downloaded from urls, as long as they are signed by a trusted signature (see Substitutes).
See Getting Substitutes from Other Servers, for more information on how to configure the daemon to get substitutes from other servers.
--no-offload
Do not use offload builds to other machines (see Using the Offload Facility). That is, always build things locally instead of offloading builds to remote machines.
--cache-failures
Cache build failures. By default, only successful builds are cached.
When this option is used, guix gc --list-failures
can be used
to query the set of store items marked as failed; guix gc
--clear-failures
removes store items from the set of cached failures.
See Invoking guix gc
.
--cores=n
-c n
Use n CPU cores to build each derivation; 0
means as many
as available.
The default value is 0
, but it may be overridden by clients, such
as the --cores option of guix build
(see Invoking guix build
).
The effect is to define the NIX_BUILD_CORES
environment variable
in the build process, which can then use it to exploit internal
parallelism—for instance, by running make -j$NIX_BUILD_CORES
.
--max-jobs=n
-M n
Allow at most n build jobs in parallel. The default value is
1
. Setting it to 0
means that no builds will be performed
locally; instead, the daemon will offload builds (see Using the Offload Facility), or simply fail.
--max-silent-time=seconds
When the build or substitution process remains silent for more than seconds, terminate it and report a build failure.
The default value is 0
, which disables the timeout.
The value specified here can be overridden by clients (see --max-silent-time).
--timeout=seconds
Likewise, when the build or substitution process lasts for more than seconds, terminate it and report a build failure.
The default value is 0
, which disables the timeout.
The value specified here can be overridden by clients (see --timeout).
--rounds=N
Build each derivation n times in a row, and raise an error if
consecutive build results are not bit-for-bit identical. Note that this
setting can be overridden by clients such as guix build
(see Invoking guix build
).
When used in conjunction with --keep-failed, the differing output is kept in the store, under /gnu/store/…-check. This makes it easy to look for differences between the two results.
--debug
Produce debugging output.
This is useful to debug daemon start-up issues, but then it may be
overridden by clients, for example the --verbosity option of
guix build
(see Invoking guix build
).
--chroot-directory=dir
Add dir to the build chroot.
Doing this may change the result of build processes—for instance if they use optional dependencies found in dir when it is available, and not otherwise. For that reason, it is not recommended to do so. Instead, make sure that each derivation declares all the inputs that it needs.
--disable-chroot
Disable chroot builds.
Using this option is not recommended since, again, it would allow build
processes to gain access to undeclared dependencies. It is necessary,
though, when guix-daemon
is running under an unprivileged user
account.
--log-compression=type
Compress build logs according to type, one of gzip
,
bzip2
, or none
.
Unless --lose-logs is used, all the build logs are kept in the localstatedir. To save space, the daemon automatically compresses them with gzip by default.
--discover[=yes|no]
Whether to discover substitute servers on the local network using mDNS and DNS-SD.
This feature is still experimental. However, here are a few considerations.
guix publish
on your LAN cannot serve
you malicious binaries, but they can learn what software you’re
installing;
It is also possible to enable or disable substitute server discovery at run-time by running:
herd discover guix-daemon on herd discover guix-daemon off
--disable-deduplication
¶Disable automatic file “deduplication” in the store.
By default, files added to the store are automatically “deduplicated”: if a newly added file is identical to another one found in the store, the daemon makes the new file a hard link to the other file. This can noticeably reduce disk usage, at the expense of slightly increased input/output load at the end of a build process. This option disables this optimization.
--gc-keep-outputs[=yes|no]
Tell whether the garbage collector (GC) must keep outputs of live derivations.
When set to yes
, the GC will keep the outputs of any live
derivation available in the store—the .drv files. The default
is no
, meaning that derivation outputs are kept only if they are
reachable from a GC root. See Invoking guix gc
, for more on GC
roots.
--gc-keep-derivations[=yes|no]
Tell whether the garbage collector (GC) must keep derivations corresponding to live outputs.
When set to yes
, as is the case by default, the GC keeps
derivations—i.e., .drv files—as long as at least one of their
outputs is live. This allows users to keep track of the origins of
items in their store. Setting it to no
saves a bit of disk
space.
In this way, setting --gc-keep-derivations to yes
causes
liveness to flow from outputs to derivations, and setting
--gc-keep-outputs to yes
causes liveness to flow from
derivations to outputs. When both are set to yes
, the effect is
to keep all the build prerequisites (the sources, compiler, libraries,
and other build-time tools) of live objects in the store, regardless of
whether these prerequisites are reachable from a GC root. This is
convenient for developers since it saves rebuilds or downloads.
--impersonate-linux-2.6
On Linux-based systems, impersonate Linux 2.6. This means that the
kernel’s uname
system call will report 2.6 as the release number.
This might be helpful to build programs that (usually wrongfully) depend on the kernel version number.
--lose-logs
Do not keep build logs. By default they are kept under localstatedir/guix/log.
--system=system
Assume system as the current system type. By default it is the
architecture/kernel pair found at configure time, such as
x86_64-linux
.
--listen=endpoint
Listen for connections on endpoint. endpoint is interpreted
as the file name of a Unix-domain socket if it starts with
/
(slash sign). Otherwise, endpoint is interpreted as a
host name or host name and port to listen to. Here are a few examples:
--listen=/gnu/var/daemon
Listen for connections on the /gnu/var/daemon Unix-domain socket, creating it if needed.
--listen=localhost
¶Listen for TCP connections on the network interface corresponding to
localhost
, on port 44146.
--listen=128.0.0.42:1234
Listen for TCP connections on the network interface corresponding to
128.0.0.42
, on port 1234.
This option can be repeated multiple times, in which case
guix-daemon
accepts connections on all the specified
endpoints. Users can tell client commands what endpoint to connect to
by setting the GUIX_DAEMON_SOCKET
environment variable
(see GUIX_DAEMON_SOCKET
).
Note: The daemon protocol is unauthenticated and unencrypted. Using --listen=host is suitable on local networks, such as clusters, where only trusted nodes may connect to the build daemon. In other cases where remote access to the daemon is needed, we recommend using Unix-domain sockets along with SSH.
When --listen is omitted, guix-daemon
listens for
connections on the Unix-domain socket located at
localstatedir/guix/daemon-socket/socket.
Next: Application Setup, Previous: Setting Up the Daemon, Up: Installation [Contents][Index]