* Remove references to Berkeley DB, including most of the

troubleshooting section.  W00t.
This commit is contained in:
Eelco Dolstra 2008-11-19 11:58:33 +00:00
parent f5325d292d
commit 07d3a38726
4 changed files with 17 additions and 143 deletions

View file

@ -60,27 +60,6 @@ env-keep-derivations = false
</varlistentry> </varlistentry>
<varlistentry xml:id="conf-gc-reserved-space"><term><literal>gc-reserved-space</literal></term>
<listitem><para>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.</para>
<para>For this reason, when Nix is run, it allocates a file
<filename>/nix/var/nix/db/reserved</filename> 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.</para>
<para>The default is <literal>1048576</literal> (1
MiB).</para></listitem>
</varlistentry>
<varlistentry><term><literal>env-keep-derivations</literal></term> <varlistentry><term><literal>env-keep-derivations</literal></term>
<listitem><para>If <literal>false</literal> (default), derivations <listitem><para>If <literal>false</literal> (default), derivations

View file

@ -96,18 +96,23 @@ ubiquitous 2.5.4a won't. Note that these are only required if you
modify the parser or when you are building from the Subversion modify the parser or when you are building from the Subversion
repository.</para> repository.</para>
<para>Nix uses Sleepycat's Berkeley DB, CWI's ATerm library and the <para>Nix uses CWI's ATerm library and the bzip2 compressor (including
bzip2 compressor (including the bzip2 library). These are included in the bzip2 library). These are included in the Nix source
the Nix source distribution. If you build from the Subversion distribution. If you build from the Subversion repository, you must
repository, you must download them yourself and place them in the download them yourself and place them in the
<filename>externals/</filename> directory. See <filename>externals/</filename> directory. See
<filename>externals/Makefile.am</filename> for the precise URLs of <filename>externals/Makefile.am</filename> for the precise URLs of
these packages. Alternatively, if you already have them installed, these packages. Alternatively, if you already have them installed,
you can use <command>configure</command>'s you can use <command>configure</command>'s
<option>--with-bdb</option>, <option>--with-aterm</option> and <option>--with-aterm</option> and <option>--with-bzip2</option>
<option>--with-bzip2</option> options to point to their respective options to point to their respective locations.</para>
locations. Note that Berkeley DB <emphasis>must</emphasis> be version
4.5; other versions may not have compatible database formats.</para> <para>If you want to be able to upgrade Nix stores from before version
0.12pre12020, you need Sleepycat's Berkeley DB version version 4.5.
(Other versions may not have compatible database formats.). Berkeley
DB 4.5 is included in the Nix source distribution. If you do not need
this ability, you can build Nix with the
<option>--disable-old-db-compat</option> configure option.</para>
</section> </section>

View file

@ -87,7 +87,7 @@ $ rm __db* log.* derivers references referrers reserved validpaths DB_CONFIG</sc
upgrading, instead of setting an exclusive lock on the profile. upgrading, instead of setting an exclusive lock on the profile.
This allows multiple <command>nix-env -i / -u / -e</command> This allows multiple <command>nix-env -i / -u / -e</command>
operations on the same profile in parallel. If a operations on the same profile in parallel. If a
<command>nix-env</command> operation sees at th end that the profile <command>nix-env</command> operation sees at the end that the profile
was changed in the meantime by another process, it will just was changed in the meantime by another process, it will just
restart. This is generally cheap because the build results are restart. This is generally cheap because the build results are
still in the Nix store.</para></listitem> still in the Nix store.</para></listitem>

View file

@ -9,117 +9,6 @@ the <link xlink:href="http://bugs.strategoxt.org/browse/NIX">Nix
bug tracker</link> for a list of currently known issues.</para> 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 dont go away (i.e.,
automatic recovery doesnt 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 doesnt work, its 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 &amp;&amp; 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> <section><title>Collisions in <command>nix-env</command></title>
<para>Symptom: when installing or upgrading, you get an error message such as <para>Symptom: when installing or upgrading, you get an error message such as
@ -187,7 +76,8 @@ Furthermore, the <literal>st_nlink</literal> field of the
<para>This only happens on very large Nix installations (such as build <para>This only happens on very large Nix installations (such as build
machines).</para> machines).</para>
<para>Quick solution: run the garbage collector.</para> <para>Quick solution: run the garbage collector. You may want to use
the <option>--max-links</option> option.</para>
<para>Real solution: put the Nix store on a file system that supports <para>Real solution: put the Nix store on a file system that supports
more than 32,000 subdirectories per directory, such as ReiserFS. more than 32,000 subdirectories per directory, such as ReiserFS.