On Sun, Jan 22, 2017 at 12:17 PM, Guillem Jover <guil...@debian.org> wrote: > Control: forcemerge 850417 -1 > > Hi > > On Fri, 2017-01-20 at 15:26:19 +0000, lkcl wrote: >> Package: dpkg >> Version: 1.18.18 >> Severity: important > >> weirdest bug i've encountered on debian, yet, in 12 years! >> simply running "apt-get build-dep blender" causes the >> /var/lib/dpkg/lock file to exist during *and after* >> the completion of that command: > > This file always exists. > >> The following NEW packages will be installed: >> libalut-dev libalut0 libass9 libavdevice-dev libavfilter-dev >> libavformat-dev >> libavresample-dev libboost-filesystem-dev libboost-filesystem1.62-dev >> libboost-locale-dev libboost-locale1.62-dev libboost-regex-dev >> libilmbase-dev libjbig-dev libjemalloc-dev liblzma-dev libopenal-dev >> libopencolorio-dev libopenexr-dev libopenimageio-dev libopenimageio-doc >> libopenjp2-7-dev libopenvdb-dev libpostproc-dev libspnav-dev libtbb-dev >> libtiff5-dev libtiffxx5 opencollada-dev python3-chardet python3-requests >> python3-six python3-urllib3 >> The following packages will be upgraded: >> libavdevice57 libavfilter6 libavformat57 libopenexr22 libpostproc54 >> libswscale-dev libswscale4 >> 7 upgraded, 33 newly installed, 0 to remove and 1566 not upgraded. >> Need to get 0 B/13.6 MB of archives. >> After this operation, 111 MB of additional disk space will be used. >> Do you want to continue? [Y/n] y >> Reading changelogs... Done >> Extracting templates from packages: 100% >> dpkg: error: dpkg status database is locked by another process >> E: Sub-process /usr/bin/dpkg returned an error code (2) >> E: Failed to process build dependencies >> >> no, there is no other command running that locks the database. >> >> if i do "rm /var/lib/dpkg/lock" and run "apt-get install libadvdevice57" >> for example it's absolutely fine: no problems. > > This should never *ever* be done:
well, it's the only thing that fixed the problem. > > <https://wiki.debian.org/Teams/Dpkg/FAQ#Q:_What_can_be_done_when_the_dpkg_lock_is_held.3F> > > I guess you run something like lsof on the lockfile to see if anything > was keeping a lock? of course. and fuser. there were absolutely no processes, programs, users, or any output of any kind, produced by *either* lsof *or* fuser. >> the moment apt-get build-dep xxxx is used, splat. > > Is this always reproducible? it is 100% reproducible. >> i'm including a complete list of all software packages (and versions) >> as this is really rather important, this one! the workaround is to manually >> list (and install) all the packages listed by apt-get build-dep. > > There is probably something else that has run a dpkg instance, there is not. > or has > locked the dpkg lock meanwhile. there is not. unfortunately, once the lock file is made, despite there being *absolutely no* other programs running, i cannot use apt-get, aptitude or dpkg... period. the *only* way which allows me to continue is to remove the lock file. > These have started appearing in recent > times (see the merged bug). So, while I don't think this is a problem > in dpkg, as we do not know what is triggering this, I have no clue where > to reassign to. yeah me neither: however it was important enough to at least list for... something. > My instinct tells me something apt related, but no > idea really. :( > > Something has probably started running dpkg or apt commands asynchronously > somewhere? that's a perfectly reasonable suggestion to make... this is a single-user system... it doesn't quite fit the symptoms of only occurring with "apt-get build-dep" but not occurring with "apt-get install"... i'll run an strace -ff -o log.txt and see what happens. l.
