[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#149491: dpkg depends hard on working F_SETLK fcntl

On Mon, Jun 10, 2002 at 02:18:08PM +0100, Andrew Suffield wrote:
> On Mon, Jun 10, 2002 at 01:02:29AM +0200, Paul Stoeber wrote:
> > dpkg refuses to operate ("unable to lock dpkg status database"),
> > if the F_SETLK fcntl doesn't work on the filesystem where
> > /var/lib/dpkg/lock is located.
> > 
> > That's bad because it's not easy to get F_SETLK to work on NFS.
> Works for me. Did you forget to start rpc.lockd?
> > I ran into this when trying to install Debian from
> > woody_netinst-20020416-powerpc.iso.
> I seem to recall having to manually bootstrap stuff from the
> installer, because it didn't start rpc.lockd automatically 
> > It would be nice if the user could at least work around this problem
> > from within the shell provided on the installation CD.  I don't currently
> > see such a workaround, but any one of the following changes to dpkg would
> > make it possible:
> <snip>
> Just use NFS locking. The whole point of fcntl F_SETLK is that it
> works over NFS, while flock() does not.

I use a small C program (http://www.tu-ilmenau.de/~past-in/trylock.tar)
that immediately determines if a given NFS setup supports locking or not.
It calls F_SETLK in the same way dpkg does.

I've tried different NFS server/client pairs, and I didn't forget
to start rpc.lockd.  The result was always the same: ENOLCK.

Maybe there's a simple newbie catch in this.  [I recall a frustrated
user who couldn't understand why `a.out' wouldn't start because
he knew nothing about $PATH.]

It can also happen that I want to use an NFS server with broken locking,
but I don't have enough administrative control over it to fix it.

All I'm asking for is one very small change to dpkg that would
allow a user to circumvent the "unable to lock dpkg status database"
brick wall.  dpkg has become boot critical in woody (well, not
really, but doing dpkg's work by hand was a nuisance), so it shouldn't
get in the way unnecessarily.  I think the database locking
is redundant if the user is careful to not start /usr/bin/dpkg
while another instance is running.  Is that correct?

Putting the lock file into a directory of its own
(change "/var/lib/dpkg/lock" to "/var/lib/dpkg/lock-dir/lock")
should be the least intrusive of my proposals.

To UNSUBSCRIBE, email to debian-dpkg-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Reply to: