Excerpts from Thomas Hood's message of Wed Mar 21 21:12:53 UTC 2012:
> There is no shortage of duplicates of this report. I am inclined to
> guess that in many cases faulty package scripts are leaving processes
> around which fail to release the config.dat lock under some
> circumstances.
>
> In order to test this hypothesis I'd like to go back in time and in each
> of the 400-odd cases find the rogue process and then figure out why it's
> running on the user's system. Obviously that's impossible. But perhaps
> we will have chances to do this in the future.
>
> I certainly don't think that the *majority* of cases has arisen from a
> package management command being run from a terminal while another
> package management process runs. I was just asking in #30 whether or
> not there are higher-level locks that should be taken by such commands,
> resulting in earlier and more useful error messages. It seems not. In
> that case I'd say that for now the error message ("debconf: DbDriver
> "config": /var/cache/debconf/config.dat is locked by another process:
> Resource temporarily unavailable") should be extended to give some
> advice about how to fix the problem... and possibly also to ask for
> information to be contributed here.
>
Perhaps an apport bug pattern could be written which would look for what
processes are holding the locks?
Excerpts from Thomas Hood's message of Wed Mar 21 21:12:53 UTC 2012: debconf/ config. dat is locked by another process:
> There is no shortage of duplicates of this report. I am inclined to
> guess that in many cases faulty package scripts are leaving processes
> around which fail to release the config.dat lock under some
> circumstances.
>
> In order to test this hypothesis I'd like to go back in time and in each
> of the 400-odd cases find the rogue process and then figure out why it's
> running on the user's system. Obviously that's impossible. But perhaps
> we will have chances to do this in the future.
>
> I certainly don't think that the *majority* of cases has arisen from a
> package management command being run from a terminal while another
> package management process runs. I was just asking in #30 whether or
> not there are higher-level locks that should be taken by such commands,
> resulting in earlier and more useful error messages. It seems not. In
> that case I'd say that for now the error message ("debconf: DbDriver
> "config": /var/cache/
> Resource temporarily unavailable") should be extended to give some
> advice about how to fix the problem... and possibly also to ask for
> information to be contributed here.
>
Perhaps an apport bug pattern could be written which would look for what
processes are holding the locks?