tdb_lock failed errors (bug #3327)

[Tony Mountifield]

I've been investigating the frequent occurrence of the following error
messages under smbclient 3.0.7 (I think it's common to all 3.0.x):

[2005/12/14 17:52:53, 5] tdb/tdbutil.c:tdb_log(725) tdb(/var/cache/samba/gencache.tdb): tdb_brlock failed (fd=3) at offset 244 rw_type=0 lck_type=14
[2005/12/14 17:52:53, 5] tdb/tdbutil.c:tdb_log(725) tdb(/var/cache/samba/gencache.tdb): tdb_brlock failed (fd=3) at offset 244 rw_type=0 lck_type=14: Bad file descriptor
[2005/12/14 17:52:53, 0] tdb/tdbutil.c:tdb_log(725) tdb(/var/cache/samba/gencache.tdb): tdb_lock failed on list 19 ltype=0 (Bad file descriptor)

I eventually discovered that it is caused by close_our_files() closing
the fd for gencache.tdb in the tdb structure (usually fd 3).

An "lsof" of any mount.smbfs process will show only fds 0, 1 and 2 open,
even though tdb->fd contains 3.

What seems to be happening is that gencache.tdb is opened before
mount.smbfs forks, and the child process assumes it is still open,
although close_all_files() has stomped on the fd.

I have no idea what the side effects of tdb_lock failing would be, but I
assume the locking is there for a purpose! According to google, this
issue has been raised from time to time, but I couldn't find any
meaningful response to it.

I think there are two possible ways to fix this, and would welcome
advice on the correct approach:

1. close_our_files() needs to avoid the inherited fd for gencache.tdb as
it does for client_fd. This has the problem that it may not be easy to
determine the correct fd.

2. gencache.tdb should be closed by mount.smbfs before forking, and the
child process should then open it again for itself. On reflection, I
think this is the better approach.

I raised a bug in bugzilla, #3327 a few weeks ago, but it doesn't appear
to have been noticed yet.

Cheers
Tony


-- 
Tony Mountifield
Work: tony at softins.co.uk - http://www.softins.co.uk
Play: tony at mountifield.org - http://tony.mountifield.org