Re: upgrade to debian 1.3

[joost@rulcmc.leidenuniv.nl (joost witteveen)]

> On Apr 29, Danny ter Haar wrote
> > During the upgrade i saw the following message:
> > 
> > Update-menus: Dpkg is locking dpkg status area: forking to background
> > and wait for /var/lib/dpkg/lock to become unlocked.
> > Setting up lynx (2.7-2) ...
> > 
> > Configuration file `/etc/lynx.cfg'
> [...]
> >  The default action is to keep your current version.
> > *** lynx.cfg (Y/I/N/O/Z) [default=N] ? unable to lock dpkg status 
> > database(/var/lib/dpkg/lock)
> > This means your system is messed up badly. Aborting.
> 
> > Somebody can shed some light on this ?
> 
> Just a guess (Joost, please comment): update-menus is expensive to run
Yes, but that's not the main reason.

> This was done by some form of waiting until dpkg's
> lock was removed, and then locking it for update-menus. Your example shows
> that this does (unfortunately) not indicate that the dpkg run is complete,
> and that this interferes with normal dpkg operation.

To be more precise, I try to lock the dpkg file, and then
_immediately_ afterwards, unlock it:

 fd=open(DPKG_LOCKFILE, O_RDWR|O_CREAT|O_TRUNC, 0660);
  fl.l_type= F_WRLCK;
  fl.l_whence= SEEK_SET;
  fl.l_start= 0;
  fl.l_len= 1;
  if (fcntl(fd,F_SETLK,&fl) == -1) {
    if (errno == EWOULDBLOCK || errno == EAGAIN)
      return 1;
    cerr<<"unable to lock dpkg status database("DPKG_LOCKFILE")"<<endl 
        <<"This means your system is messed up badly. Aborting.";
    exit(1);
  }
  fl.l_type= F_UNLCK;
  fl.l_whence= SEEK_SET;
  fl.l_start= 0;
  fl.l_len= 1;
  if (fcntl(fd,F_SETLK,&fl) == -1){

Note also that the error message is from update-menus
(yes, I just chaged update-menus to put it's name before that error
message). The code comes directly from dpkg, btw, but I chaged the
error message. At the line of the "unable to ...", dpkg has (dpkg/lib/lock.c):

  if (fcntl(dblockfd,F_SETLK,&fl) == -1) {
    if (errno == EWOULDBLOCK || errno == EAGAIN)
      ohshit("status database area is locked - another dpkg/dselect is running")
;
    ohshite("unable to lock dpkg status database");


> Maybe this is a solution: let update-menus use a lock file of its own to
> prevent concurrent runs, and have the single active run wait until dpkg's
> lock file is gone before doing the expensive operations?

update-menus acutally does have it's own lock file (/var/run/update-menus.pid).

The main reason why update-menus checks for a running dpkg is that
it has to know what packages are installed (to create the menu's
files). While dpkg is still running, it doesn't update the
/var/lib/dpkg/info/status file, and thus update-menus would see the
old status file (the one from before dpkg was started).

I'm not sure there was actually an error in the above lynx install
session (appart from the possibly wrong error message) Apparently, the
manpage for fcntl has:
       F_SETLK  The  lock  is  set  (when  l_type  is  F_RDLCK or
                F_WRLCK) or cleared (when it is F_UNLCK).  If the
                lock  is  held by someone else, this call returns
                -1 and sets errno to EACCES or EAGAIN.

So, probably I should also test for EACCES. (why doesn't dpkg does this?)

Anybody know more about this?


-- 
joost witteveen, joostje@debian.org
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-user-request@lists.debian.org . 
Trouble?  e-mail to templin@bucknell.edu .