On Mon, Oct 25, 2004 at 10:51:34PM +0200, Marcin Owsiany wrote:
> Recently a similar error started to appear on one of my machines, running
> woody. It has 4GB of free space in /var and 40 MB of free space in /tmp. Here
> is the end of the output of:
>
> start-stop-daemon --start --pidfile /dev/null \
> --startas /usr/lib/man-db/mandb --oknodo --chuid man \
> -- --no-purge -dp
This is indeed a little more useful than Ian's output, since
unfortunately his debug output shows no signs of any error.
> -------< snip >------------------------------------------------------------
> Processing manual pages under /usr/X11R6/man...
> update_db(): 1078795713
> Testing /usr/X11R6/man for new files
> subdirectory man1 has been 'modified'
> Updating index cache for path `/usr/X11R6/man'. Wait...
> ult_src: File /usr/X11R6/man/man1/beforelight.1x.gz in mantree /usr/X11R6/man
> ++priv_drop_count = 1
> ++priv_drop_count = 2
> --priv_drop_count = 1
> The following command done with dropped privs
> /bin/gzip -dc /usr/X11R6/man/man1/beforelight.1x.gz > /tmp/zmano1Ahim
> --priv_drop_count = 0
> ++priv_drop_count = 1
> ++priv_drop_count = 2
> --priv_drop_count = 1
> ++priv_drop_count = 2
> --priv_drop_count = 1
> --priv_drop_count = 0
> "beforelight - screen saver"
> raw_whatis = beforelight - screen saver
> base_name = `beforelight', id = A
> mandb: cannot insert unused key beforelight
> mandb: index cache /var/cache/man/X11R6/10765 corrupt
> -------< snip >------------------------------------------------------------
>
> If you need the full output, just let me know.
I imagine I'm too late now!
> The output of "/bin/gzip -dc /usr/X11R6/man/man1/beforelight.1x.gz" looks
> normal. After stripping comments, it is:
The contents of the file in question aren't relevant.
I've heard no similar reports since switching to gdbm, and I therefore
suspect that doing so has papered over this bug. I'd still like to
figure out what was going on, though, since the Berkeley DB backend is
still present (and indeed the default, questionably) in the upstream
source.
I have two hypotheses which fit the observed facts:
1) Two copies of mandb are running simultaneously and manage to create
a corrupt database file between them.
2) Both a simple key and a multi key (these are internal terms I'm
using for my own reference) for a given item exist in the database.
I am sceptical of 1); mandb's locking strategy is not exactly
commendable, but on a single machine without any network file systems
being involved it should be quite safe to copy the database to a
temporary file, operate on that, and then move it back into place. Thus
I think the most probable scenario is 2).
It should be relatively straightforward to add a bit more error checking
to deal with this case, but I'd also like to work out what caused it. I
will attempt that at some later time ...
--
Colin Watson [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
