Next: , Previous: , Up: Installation   [Contents][Index]

2.5 Invoking 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

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. Be aware that using a directory other than /tmp can affect build results—for example, with a longer directory name, a build process that uses Unix-domain sockets might hit the name length limitation for sun_path, which it would otherwise not hit.

The build directory is automatically deleted upon completion, unless the build failed and the client specified --keep-failed (see --keep-failed).

The following command-line options are supported:


Take users from group to run build processes (see build users).


Do not use substitutes for build products. That is, always build things locally instead of allowing downloads of pre-built binaries (see Substitutes).

By default substitutes are used, unless the client—such as the guix package command—is explicitly invoked with --no-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).


Consider urls the default whitespace-separated list of substitute source URLs. When this option is omitted, ‘’ is used ( is a mirror of

This means that substitutes may be downloaded from urls, as long as they are signed by a trusted signature (see Substitutes).


Do not use the build hook.

The build hook is a helper program that the daemon can start and to which it submits build requests. This mechanism is used to offload builds to other machines (see Daemon Offload Setup).


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.

-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.

-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 Daemon Offload Setup), or simply fail.


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).


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).


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 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.


Disable compression of the build logs.

Unless --lose-logs is used, all the build logs are kept in the localstatedir. To save space, the daemon automatically compresses them with bzip2 by default. This option disables that.


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.


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 GC roots.


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.

Note that when both --gc-keep-derivations and --gc-keep-outputs are used, 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 live. This is convenient for developers since it saves rebuilds or downloads.


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.


Do not keep build logs. By default they are kept under localstatedir/guix/log.


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 for connections on socket, the file name of a Unix-domain socket. The default socket is localstatedir/daemon-socket/socket. This option is only useful in exceptional circumstances, such as if you need to run several daemons on the same machine.

Next: , Previous: , Up: Installation   [Contents][Index]