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: