203 lines
6.3 KiB
XML
203 lines
6.3 KiB
XML
<appendix xmlns="http://docbook.org/ns/docbook"
|
||
xmlns:xlink="http://www.w3.org/1999/xlink">
|
||
|
||
<title>Troubleshooting</title>
|
||
|
||
|
||
<para>This section provides solutions for some common problems. See
|
||
the <link xlink:href="https://bugs.cs.uu.nl/browse/NIX">Nix
|
||
bug tracker</link> for a list of currently known issues.</para>
|
||
|
||
|
||
<section><title>Berkeley DB: <quote>Cannot allocate memory</quote></title>
|
||
|
||
<para>Symptom: Nix operations (in particular the
|
||
<command>nix-store</command> operations <option>--gc</option>,
|
||
<option>--verify</option>, and <option>--clear-substitutes</option> —
|
||
the latter being called by <command>nix-channel --update</command>)
|
||
failing:
|
||
|
||
<screen>
|
||
$ nix-store --verify
|
||
error: Db::del: Cannot allocate memory</screen>
|
||
|
||
</para>
|
||
|
||
<para>Possible solution: make sure that no Nix processes are running,
|
||
then do:
|
||
|
||
<screen>
|
||
$ cd /nix/var/nix/db
|
||
$ rm __db.00*</screen>
|
||
|
||
</para>
|
||
|
||
</section>
|
||
|
||
|
||
<section><title>Berkeley DB gives weird error messages</title>
|
||
|
||
<para>Symptom: you get error messages such as
|
||
|
||
<screen>
|
||
Berkeley DB message: Finding last valid log LSN: file: 1 offset 28
|
||
Berkeley DB error: file validpaths (meta pgno = 0) has LSN [483][34721].
|
||
Berkeley DB error: end of log is [1][28]
|
||
Berkeley DB error: /nix/var/nix/db/validpaths: unexpected file type or format</screen>
|
||
|
||
or other weird Berkeley DB errors, and they don’t go away (i.e.,
|
||
automatic recovery doesn’t work). This may be the case after a system
|
||
crash.</para>
|
||
|
||
<para>Solution: first try to run <command>db_recover</command> and
|
||
then <link linkend='refsec-nix-store-verify'><command>nix-store
|
||
--verify</command></link>:
|
||
|
||
<screen>
|
||
$ db_recover -h /nix/var/nix/db
|
||
$ nix-store --verify</screen>
|
||
|
||
(Make sure that you have the right version of
|
||
<command>db_recover</command>, namely, Berkeley DB 4.4 for Nix 0.10,
|
||
and 4.5 for Nix 0.11.)</para>
|
||
|
||
<para>If that doesn’t work, it’s time to bring out the big guns:
|
||
|
||
<screen>
|
||
$ cd /nix/var/nix
|
||
$ cp -pr db db-backup <lineannotation>(making a backup just in case)</lineannotation>
|
||
$ cd db
|
||
$ rm __db.* log* <lineannotation>(removing the Berkeley DB environment)</lineannotation>
|
||
$ mkdir tmp
|
||
$ for i in *; do db_dump $i | (cd tmp && db_load $i); done
|
||
<lineannotation>(ignore error messages about non-database files like “reserved”)</lineannotation>
|
||
$ mv tmp/* .
|
||
$ nix-store --verify</screen>
|
||
|
||
</para>
|
||
|
||
</section>
|
||
|
||
|
||
<section><title>Berkeley DB out of locks</title>
|
||
|
||
<para>It is possible, especially in <command>nix-store
|
||
--verify</command> or when running the garbage collector, to run out
|
||
of Berkeley DB locks, like this:
|
||
|
||
<screen>
|
||
$ nix-store --verify
|
||
checking path existence
|
||
checking path realisability
|
||
checking the derivers table
|
||
checking the references table
|
||
Berkeley DB error: Lock table is out of available object entries
|
||
error: Db::get: Cannot allocate memory</screen>
|
||
|
||
</para>
|
||
|
||
<para>A workaround is to increase the number of locks that Berkeley DB
|
||
allocates. (The real solution would be for Nix to not use so many
|
||
locks.) This can be done by putting the following in the file
|
||
<filename>/nix/var/nix/db/<link
|
||
xlink:href="http://www.oracle.com/technology/documentation/berkeley-db/db/ref/env/db_config.html">DB_CONFIG</link></filename>:
|
||
|
||
<programlisting>
|
||
set_lk_max_locks 100000
|
||
set_lk_max_lockers 100000
|
||
set_lk_max_objects 100000
|
||
</programlisting>
|
||
|
||
(Increase these numbers if necessary.) Then make sure that there are
|
||
no running Nix processes and delete the Berkeley DB environment:
|
||
|
||
<screen>
|
||
$ rm /nix/var/nix/db/__db.*</screen>
|
||
|
||
The Berkeley DB environment is automatically recreated with the new
|
||
limits when you run any Nix command.</para>
|
||
|
||
</section>
|
||
|
||
|
||
<section><title>Collisions in <command>nix-env</command></title>
|
||
|
||
<para>Symptom: when installing or upgrading, you get an error message such as
|
||
|
||
<screen>
|
||
$ nix-env -i docbook-xml
|
||
...
|
||
adding /nix/store/s5hyxgm62gk2...-docbook-xml-4.2
|
||
collission between `/nix/store/s5hyxgm62gk2...-docbook-xml-4.2/xml/dtd/docbook/calstblx.dtd'
|
||
and `/nix/store/06h377hr4b33...-docbook-xml-4.3/xml/dtd/docbook/calstblx.dtd'
|
||
at /nix/store/...-builder.pl line 62.</screen>
|
||
|
||
</para>
|
||
|
||
<para>The cause is that two installed packages in the user environment
|
||
have overlapping filenames (e.g.,
|
||
<filename>xml/dtd/docbook/calstblx.dtd</filename>. This usually
|
||
happens when you accidentally try to install two versions of the same
|
||
package. For instance, in the example above, the Nix Packages
|
||
collection contains two versions of <literal>docbook-xml</literal>, so
|
||
<command>nix-env -i</command> will try to install both. The default
|
||
user environment builder has no way to way to resolve such conflicts,
|
||
so it just gives up.</para>
|
||
|
||
<para>Solution: remove one of the offending packages from the user
|
||
environment (if already installed) using <command>nix-env
|
||
-e</command>, or specify exactly which version should be installed
|
||
(e.g., <literal>nix-env -i docbook-xml-4.2</literal>).</para>
|
||
|
||
<para>Alternatively, you can modify the user environment builder
|
||
script (in
|
||
<filename><replaceable>prefix</replaceable>/share/nix/corepkgs/buildenv/builder.pl</filename>)
|
||
to implement some conflict resolution policy. E.g., the script could
|
||
be modified to rename conflicting file names, or to pick one over the
|
||
other.</para>
|
||
|
||
</section>
|
||
|
||
|
||
<section><title><quote>Too many links</quote> error in the Nix
|
||
store</title>
|
||
|
||
|
||
<para>Symptom: when building something, you get an error message such as
|
||
|
||
<screen>
|
||
...
|
||
<literal>mkdir: cannot create directory `/nix/store/<replaceable>name</replaceable>': Too many links</literal></screen>
|
||
|
||
</para>
|
||
|
||
<para>This is usually because you have more than 32,000 subdirectories
|
||
in <filename>/nix/store</filename>, as can be seen using <command>ls
|
||
-l</command>:
|
||
|
||
<screen>
|
||
$ ls -l /nix/store
|
||
drwxrwxrwt 32000 nix nix 4620288 Sep 8 15:08 store</screen>
|
||
|
||
The <literal>ext2</literal> file system is limited to a inode link
|
||
count of 32,000 (each subdirectory increasing the count by one).
|
||
Furthermore, the <literal>st_nlink</literal> field of the
|
||
<function>stat</function> system call is a 16-bit value.</para>
|
||
|
||
<para>This only happens on very large Nix installations (such as build
|
||
machines).</para>
|
||
|
||
<para>Quick solution: run the garbage collector.</para>
|
||
|
||
<para>Real solution: put the Nix store on a file system that supports
|
||
more than 32,000 subdirectories per directory, such as ReiserFS.
|
||
(This doesn’t solve the <literal>st_nlink</literal> limit, but
|
||
ReiserFS lies to the kernel by reporting a link count of 1 if it
|
||
exceeds the limit.)</para>
|
||
|
||
</section>
|
||
|
||
|
||
|
||
</appendix>
|