Re: upgrade to debian 1.3
> In message <[EMAIL PROTECTED]> you wrote: > ... > >I'm not sure there was actually an error in the above lynx install > >session (appart from the possibly wrong error message) > ... 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?) > > Perhaps dpkg mmaps the file, so it always gets EAGAIN. No, it doesn't (read the code I showed, and you'll see that errno excactly is not EAGAIN, that's what I test for). > Anyway, I had this error while dpkg was installing hdimage for dosemu. > Everything got installed fine, so the error message is in error. :) update-menus wasn't run, that's all (very slight error). > You probably should log messages via syslog so that they don't mess > with output from foreground jobs. Fortunatly I didn't, as otherwise people never would see when it happens. I am glad I now at least know that the fcntl() call also can give something else than EWOULDBLOCK or EAGAIN (that's what these messages prove), I'll just go and check what the other thing is (probably it's EACCES). > AFA I can see open() should block > until dpkg run is complete The fd=open(DPKG_LOCKFILE, O_RDWR|O_CREAT|O_TRUNC, 0660); call above doesn't block. (otherwise, none of the messages above would appear!). > -- the only test I can think of is to poll > with non-blocking open() and see if it makes any difference. So this is not needed. -- joost witteveen, [EMAIL PROTECTED] #!/bin/perl -sp0777i
Re: upgrade to debian 1.3
In message <[EMAIL PROTECTED]> you wrote: ... >I'm not sure there was actually an error in the above lynx install >session (appart from the possibly wrong error message) ... 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?) Perhaps dpkg mmaps the file, so it always gets EAGAIN. Anyway, I had this error while dpkg was installing hdimage for dosemu. Everything got installed fine, so the error message is in error. :) You probably should log messages via syslog so that they don't mess with output from foreground jobs. AFA I can see open() should block until dpkg run is complete -- the only test I can think of is to poll with non-blocking open() and see if it makes any difference. Dimitri -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: upgrade to debian 1.3
> 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")"< 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, [EMAIL PROTECTED]
#!/bin/perl -sp0777i
Re: upgrade to debian 1.3
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, so it was modified not to run for each individual package install, but for each dpkg install session. 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. 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? Greetings, Ray -- ART A friend of mine in Tulsa, Okla., when I was about eleven years old. I'd be interested to hear from him. There are so many pseudos around taking his name in vain. - The Hipcrime Vocab by Chad C. Mulligan -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
