3.5 Invoking guix gc

Packages that are installed but not used may be garbage-collected. The guix gc command allows users to explicitly run the garbage collector to reclaim space from the /gnu/store directory. It is the only way to remove files from /gnu/store—removing files or directories manually may break it beyond repair!

The garbage collector has a set of known roots: any file under /gnu/store reachable from a root is considered live and cannot be deleted; any other file is considered dead and may be deleted. The set of garbage collector roots includes default user profiles, and may be augmented with guix build --root, for example (see Invoking guix build).

Prior to running guix gc --collect-garbage to make space, it is often useful to remove old generations from user profiles; that way, old package builds referenced by those generations can be reclaimed. This is achieved by running guix package --delete-generations (see Invoking guix package).

The guix gc command has three modes of operation: it can be used to garbage-collect any dead files (the default), to delete specific files (the --delete option), to print garbage-collector information, or for more advanced queries. The garbage collection options are as follows:

--collect-garbage[=min]

-C [min]

Collect garbage—i.e., unreachable /gnu/store files and sub-directories. This is the default operation when no option is specified.

When min is given, stop once min bytes have been collected. min may be a number of bytes, or it may include a unit as a suffix, such as MiB for mebibytes and GB for gigabytes (see size specifications in GNU Coreutils).

When min is omitted, collect all the garbage.

--delete

-d

Attempt to delete all the store files and directories specified as arguments. This fails if some of the files are not in the store, or if they are still live.

--list-failures

List store items corresponding to cached build failures.

This prints nothing unless the daemon was started with --cache-failures (see --cache-failures).

--clear-failures

Remove the specified store items from the failed-build cache.

Again, this option only makes sense when the daemon is started with --cache-failures. Otherwise, it does nothing.

--list-dead

Show the list of dead files and directories still present in the store—i.e., files and directories no longer reachable from any root.

--list-live

Show the list of live store files and directories.

In addition, the references among existing store files can be queried:

--references

--referrers

List the references (respectively, the referrers) of store files given as arguments.

--requisites

-R

List the requisites of the store files passed as arguments. Requisites include the store files themselves, their references, and the references of these, recursively. In other words, the returned list is the transitive closure of the store files.

See Invoking guix size, for a tool to profile the size of an element’s closure. See Invoking guix graph, for a tool to visualize the graph of references.

Lastly, the following options allow you to check the integrity of the store and to control disk usage.

--verify[=options]

Verify the integrity of the store.

By default, make sure that all the store items marked as valid in the daemon’s database actually exist in /gnu/store.

When provided, options must a comma-separated list containing one or more of contents and repair.

When passing --verify=contents, the daemon will compute the content hash of each store item and compare it against its hash in the database. Hash mismatches are reported as data corruptions. Because it traverses all the files in the store, this command can take a long time, especially on systems with a slow disk drive.

Using --verify=repair or --verify=contents,repair causes the daemon to try to repair corrupt store items by fetching substitutes for them (see Substitutes). Because repairing is not atomic, and thus potentially dangerous, it is available only to the system administrator.

--optimize

Optimize the store by hard-linking identical files—this is deduplication.

The daemon performs deduplication after each successful build or archive import, unless it was started with --disable-deduplication (see --disable-deduplication). Thus, this option is primarily useful when the daemon was running with --disable-deduplication.