Poor resolution of "database locked" problem

Confirmed on two very different machines, this happened to me on a Dell Inspiron 8100 laptop, and an AMD X64 4800 desktop.

It does seem to only need a text change to the error message to imform teh user what to do, as the original reporter said, to provide a satisfactory fix, but it would be even better to automate this.

The dialog should say something like "If you are not running another instance of Adept, click fix." And then a button to run the command to fix it and restart Adept.

I totally agree. Also, when an installation hangs/is interrupted, adept should unlock itself automatically.

Confirmed , and I agree.

I get the same basic issue with "sudo aptitude update". It was hanging on one of the package repositories, so I had to ctrl-C it. Subsequent attempt to re-run the command gave me this error:

E: Could not get lock /var/lib/apt/lists/lock - open (11 Resource temporarily unavailable)
E: Couldn't lock list directory..are you root?

Cancelling a hanged aptitude/apt-get/adept operation should be considered a first-class operation that leaves the system in a usable state.

Good news: I have created a small Python tool called "Adept Resolver"that detects and fixes this problem. It has a simple KDE GUI as well.

However, in order to make Adept compatible with this tool, we need to make Adept realize that "dpkg --configure -a" is required. The "apt-get" application is able to do that, therefore we just need a helping hand that could port this "realize we need a dpkg --configure" feature from apt-get to C++ Adept. Is there anyone who would like to step up?

I'm going to try and take care of this bug. Marked it as "In Progress" because a fix (the Adept Resolver tool) is currently underway as a branch in Launchpad: https://code.launchpad.net/~martin.bohm/adept/adept-resolver .

my bug report (would of saved allot of my time posting it if it could of found This and just added an small comment as i am now)
https://bugs.launchpad.net/ubuntu/+source/adept/+bug/123343

java made mine stop but in any case it should be cleaned up (is that tool ready yet?)

I believe what is proposed is avoiding to fix the real problem.
I believe one of the real problem is at:
adept-2.1.2ubuntu27/adept/updater/app.cpp where we have:

    aptFront::Manager m;
     m.setProgressCallback( m_progress->callback() );
     m.setUpdateInterval( 100000 );
     try {
         m_stack->raiseWidget( m_progress );
         m.download();
         m_stack->raiseWidget( m_commitProgress );
         m.commit();
     } catch ( exception::OperationCancelled ) {
     } catch ( ... ) {
         KMessageBox::sorry(
             this, i18n( "There was an error commiting changes. "
                         "Possibly there was a problem downloading some "
                         "packages or the commit would break packages. "
                         ),
             i18n( "Could not commit changes" ) );
     }

My feeling is that m.commit() make a new instance of dpkg installed all the packages downloaded in m.download().
But when any error happen in that, KMessageBox::sorry is shown, but I did observed that while it is shown, I can
see the packages continue to be installed in details window.

So if one would wait for the packages for being all installed before clicking Ok, there would no problem.
But if you click ok button before all packages finished installing, adept quit. While quitting, it make the spawn
dpkg process to quit too, while it is still installing stuff. This make it kept a lock on package database.

My suggestion would be to add some code to wait for the m.commit() to finish just after the sorry MessageBox, rather
than quit right away.

But I am still searching the code of aptFront::Manager to better understand what is still just an hypothesis.
And I am afraid to not know enough to code to 'wait for the m.commit() to finish'.

On Monday 02 July 2007 12:22:14 Paul Dufresne wrote:
> I believe what is proposed is avoiding to fix the real problem.
> I believe one of the real problem is at:
> adept-2.1.2ubuntu27/adept/updater/app.cpp where we have:
>
> aptFront::Manager m;
> m.setProgressCallback( m_progress->callback() );
> m.setUpdateInterval( 100000 );
> try {
> m_stack->raiseWidget( m_progress );
> m.download();
> m_stack->raiseWidget( m_commitProgress );
> m.commit();
> } catch ( exception::OperationCancelled ) {
> } catch ( ... ) {
> KMessageBox::sorry(
> this, i18n( "There was an error commiting changes. "
> "Possibly there was a problem downloading some "
> "packages or the commit would break packages. "
> ),
> i18n( "Could not commit changes" ) );
> }
>
> My feeling is that m.commit() make a new instance of dpkg installed all the
> packages downloaded in m.download(). But when any error happen in that,
> KMessageBox::sorry is shown, but I did observed that while it is shown, I
> can see the packages continue to be installed in details window.
>
> So if one would wait for the packages for being all installed before
> clicking Ok, there would no problem. But if you click ok button before all
> packages finished installing, adept quit. While quitting, it make the spawn
> dpkg process to quit too, while it is still installing stuff. This make it
> kept a lock on package database.
>
> My suggestion would be to add some code to wait for the m.commit() to
> finish just after the sorry MessageBox, rather than quit right away.
>
> But I am still searching the code of aptFront::Manager to better understand
> what is still just an hypothesis. And I am afraid to not know enough to
> code to 'wait for the m.commit() to finish'.

I don't believe this is actually the problem. Remember, apt is still managing
the database on this end, so if there is something that goes wrong with the
package (and oh how many things can go wrong with a package) there's not much
adept can do to handle this error other than to actually tell the user about
it and quit. I don't think that locks the database though. Have you
actually had a package that locks the database in this manner?

--
~ manchicken <><
(A)bort, (R)etry, (I)nfluence with large hammer.
09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0

Please avoid sending me Word or PowerPoint attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html

On Monday 02 July 2007 12:22:14 Paul Dufresne wrote:
> I believe what is proposed is avoiding to fix the real problem.
> I believe one of the real problem is at:
> adept-2.1.2ubuntu27/adept/updater/app.cpp where we have:
>
> aptFront::Manager m;
> m.setProgressCallback( m_progress->callback() );
> m.setUpdateInterval( 100000 );
> try {
> m_stack->raiseWidget( m_progress );
> m.download();
> m_stack->raiseWidget( m_commitProgress );
> m.commit();
> } catch ( exception::OperationCancelled ) {
> } catch ( ... ) {
> KMessageBox::sorry(
> this, i18n( "There was an error commiting changes. "
> "Possibly there was a problem downloading some "
> "packages or the commit would break packages. "
> ),
> i18n( "Could not commit changes" ) );
> }
>
> My feeling is that m.commit() make a new instance of dpkg installed all the
> packages downloaded in m.download(). But when any error happen in that,
> KMessageBox::sorry is shown, but I did observed that while it is shown, I
> can see the packages continue to be installed in details window.
>
> So if one would wait for the packages for being all installed before
> clicking Ok, there would no problem. But if you click ok button before all
> packages finished installing, adept quit. While quitting, it make the spawn
> dpkg process to quit too, while it is still installing stuff. This make it
> kept a lock on package database.
>
> My suggestion would be to add some code to wait for the m.commit() to
> finish just after the sorry MessageBox, rather than quit right away.
>
> But I am still searching the code of aptFront::Manager to better understand
> what is still just an hypothesis. And I am afraid to not know enough to
> code to 'wait for the m.commit() to finish'.

I also believe that m.commit() is a synchronous call... so I believe that it
does wait for the m.commit() to finish. I could be wrong though.

--
~ manchicken <><
(A)bort, (R)etry, (I)nfluence with large hammer.
09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0

Please avoid sending me Word or PowerPoint attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html

>I also believe that m.commit() is a synchronous call... so I believe that it does wait for the m.commit() to finish. I could be wrong though.
Well, by experience I know I see in the details window that it continue while showing the message.
So I firmly inclined to believe it is not so synchronous.

I have found in source package libapt-front:
void Manager::commit()
{
    if (!m_pm)
        throw exception::InternalError( "Tried to commit without PM" );

    // mornfall: is it me or this looks like a race?
    while (1) {
        _system->UnLock(); // unlock for dpkg to take over
        pkgPackageManager::OrderResult Res = m_pm->DoInstall(-1);
        if (Res == pkgPackageManager::Completed) {
            _system->Lock(); // regain lock
            delete m_pm;
            m_pm = 0;
            cache::Global::get( m_cache ).reopen(); // reopen cache
            return;
        } else if (Res == pkgPackageManager::Failed) {
            throw exception::Error( "Error installing packages" );
        }
        exception::checkGlobal( "Error installing packages" );
        getArchives();
    }
}

I suppose PM is Package Manager.
I guess now I am searching DoInstall method to try to prove it is asynchronous.
My guess is still that DoInstall launch dpkg to install all the downloaded packages, and may return with pkgPackageManager::Failed
and continue installing packages in the background.

Here's a patch for this issue. After investigating the work necessary for this fix, I've discovered that it would be just as simple to call dpkg directly rather than using another script to do this. I know this seems like duplication of work, and I greatly apologize for this, but in the interest of reducing dependencies and keeping things simple, I've got this working in C++.

No matter which way we went with this, it requires some tinkering in how adept initializes its connection with the dpkg database. Here's the patch, and it could probably use an extra pair of eyes.

Personally I've got lost trying to figure out how things were working.
So I guess I'll not object to something simple that just do the equivalent of 'dpkg --configure -a'.

Patch applied and uploaded, will close the bug when someone confirms it fixes the issue.

Confirmed

I don't know if it fixes the problem, but in Kubuntu 7.10 tribe5 I still have this problem.
Clicking on "Yes" -> I would like to attempt to resolve the problem does not resolve the problem, instead it crashes.

yes on beta gutsy I still experience the problem described by nfinity if I click on YES
and the crash is not usable
( a dpkg --configure -a was required )

Still crashing in Gutsy on clicking "yes". Apt-get is smart enough to determine that dpkg --configure -a is required, so this should be possible for Adept too. See also the related bug #172592.

As the fix obviously hasn't improved anything, I'm resetting the status to "confirmed".

I'm changing the status of this bug to In Progress, since a fix has been, in fact, released, but not working perfectly.

Launching Adept will trigger a popup which asks how the user wants to resolve the locked database problem. If the user chooses Yes, the dpkg command will be run, but it will also crash Adept. In my case, Adept was usable after that crash. It still needs a bit more work.

omg i was loosing my mind till i found this page thankx all this must have worked cause after the dpkg --configure -a in terminal "sudo dpkg --configure -a" i dont get the error message so now off to install beryl

I've the same problem with hardy alpha 4. From the message box ""Another process is using the packaging system database (probably some other Adept application or apt-get or aptitude).Would you like to attempt to resolve this problem? No will enter read-only mode and Cancel to quit and resolve this issue yourself." I select "YES" button.
Adept manager crashed with exit code 6.

Confirmed hardy beta (64bit). This bug was the only way I figured out how to fix it.

I was having multiple problems with Adept refusing to install/resintall certain package before this happened. Then after a few attempts it refused to open. Using `dpkg --configure -a` allowed Adept to restart & fixed the package commit problems earlier.

Maybe there are two bugs: One that Adept doesn't notice the db is hosed when it fails to commit & one that doesn't notice the db is hosed when it can't start.

Hi,
I recently opened a new bug report called "Cannot update packages at all" Bug no <email address hidden>
However, on reading this bug report I think that this is the problem I am experiencing. I tried downloading the patch but it loads as a Text file. Being quite new to this I wondered if somone could help a newbie apply thi patch to see if it fixes my problems? I do get the database locked messages and I cannot use Adept at all.

Thanks in anticipation.

James...New Linuxer

James: Thanks for your interest in testing. However, the attached patch has already been applied and it seems it still doesn't fix the problem in some situations such as yours. You should be able to work around this bug by running:
dpkg --configure -a

On Wed, 02 Apr 2008 19:36:53 +0100, Yuriy Kozlov <email address hidden>
wrote:

> James: Thanks for your interest in testing. However, the attached patch
> has already been applied and it seems it still doesn't fix the problem
> in some situations such as yours. You should be able to work around
> this bug by running:
> dpkg --configure -a

Hi Yuriy,
             I've tried everything I can find on the subject and still
nothing :(

james@K-Asus:~$ sudo dpkg --configure -a
dpkg: status database area is locked by another process

This was the result!

You say the patch has been applied but...I didn't apply it. Do I take it
that the patch is already included in the distribution I have installed?
Also, could this locked database have anything to do with a failed attempt
to install SuSE Linux? I just installed Kubuntu over the top and it
reformatted the partitions anyway? SUSE did not make half as good a job
of setting up my system that Kubuntu did, hence my return to it! :)

If you have any further suggestins I would appreciate it. Should I re
install?

James

--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

Try this command, it should solve the problem:
sudo fuser -vki /var/lib/dpkg/lock; sudo dpkg --configure -a

Yes, the patch is already applied in the distribution. This has nothing to do with a failed attempt to install SuSE, it has to do with a failed attempt to install a package in Adept and Adept failing to handle the error properly. There is no need to reinstall the system, the above command should fix it.

Hi all,
 Some comments. I have apt Version 0.7.9ubuntu15

I was doing sudo aptitude update
While downloading the index one of the index files was corrupt or something.
It did the whole cycle of the update.
Then I tried to re-update the index & the following things came up :-

shirish@Mugglewille:~$ sudo aptitude update
E: Could not get lock /var/lib/apt/lists/lock - open (11 Resource temporarily unavailable)
E: Couldn't lock list directory..are you root?
shirish@Mugglewille:~$ sudo fuser -vki /var/lib/dpkg/lock; sudo dpkg --configure -a
shirish@Mugglewille:~$ sudo aptitude update
E: Could not get lock /var/lib/apt/lists/lock - open (11 Resource temporarily unavailable)
E: Couldn't lock list directory..are you root?
shirish@Mugglewille:~$ dpkg --configure -a
dpkg: requested operation requires superuser privilege
shirish@Mugglewille:~$ sudo dpkg --configure -a
shirish@Mugglewille:~$ sudo aptitude update
E: Could not get lock /var/lib/apt/lists/lock - open (11 Resource temporarily unavailable)
E: Couldn't lock list directory..are you root?

As one can see none of the workarounds told above works/worked for me. :(
Which means either I need to shutdown and/or restart the machine or
do the

sudo killall apt aptitude apt-get

Of course that's not the recommended thing but that's what works for me most of the time.

Fixed in 3.0 beta 2.