[pacman-dev] [BUG] pacman freezes and eats up all the cpu
In a moment of distraction during a pacman -U, while it was doing the conflict checking, I removed the package I was installing from another console. The missing package was correctly detected, but then another error came up, and pacman hung taking the cpu to 100%. Even ctrl-c couldn't stop it, I had to kill it. Here's the log: [root@paradigm ~]# LANG=en_US pacman -U /home/bardo/packages/amsn-extras-svn/amsn-extras-svn-8414-1-i686.pkg.tar.gz loading package data... done. checking dependencies... done. cleaning up... done. (1/1) checking for file conflicts [####################] 100% error: failed to commit transaction (cannot open package file) error: failed to release transaction (could not commit transaction) [1]+ Stopped LANG=en_US pacman -U /home/bardo/packages/amsn-extras-svn/amsn-extras-svn-8414-1-i686.pkg.tar.gz [root@paradigm ~]# bardo
On 4/10/07, bardo <ilbardo@gmail.com> wrote:
In a moment of distraction during a pacman -U, while it was doing the conflict checking, I removed the package I was installing from another console. The missing package was correctly detected, but then another error came up, and pacman hung taking the cpu to 100%. Even ctrl-c couldn't stop it, I had to kill it. Here's the log:
[root@paradigm ~]# LANG=en_US pacman -U /home/bardo/packages/amsn-extras-svn/amsn-extras-svn-8414-1-i686.pkg.tar.gz loading package data... done. checking dependencies... done. cleaning up... done. (1/1) checking for file conflicts [####################] 100% error: failed to commit transaction (cannot open package file) error: failed to release transaction (could not commit transaction)
[1]+ Stopped LANG=en_US pacman -U /home/bardo/packages/amsn-extras-svn/amsn-extras-svn-8414-1-i686.pkg.tar.gz [root@paradigm ~]#
How did you get pacman to run twice without it warning about an existing lock file? -Dan
On 4/10/07, Dan McGee <dpmcgee@gmail.com> wrote:
How did you get pacman to run twice without it warning about an existing lock file?
I removed it manually. I thought it was obvious, since I had to kill the process :) bardo
On 4/10/07, bardo <ilbardo@gmail.com> wrote:
On 4/10/07, Dan McGee <dpmcgee@gmail.com> wrote:
How did you get pacman to run twice without it warning about an existing lock file?
I removed it manually. I thought it was obvious, since I had to kill the process :)
Well I don't know that this is a bug if you started doing that. We'd need a much better bug report and a way to reproduce it. If you can, the output from pacman with the --debug flag would be useful, along with a specific version. -Dan
On 4/10/07, Dan McGee <dpmcgee@gmail.com> wrote:
Well I don't know that this is a bug if you started doing that. We'd need a much better bug report and a way to reproduce it.
Ok, I think I didn't make myself clear in the first place, and then I misinterpreted your reply. I didn't run pacman twice. I removed the *package file* I was installing with 'rm', I never called 'pacman -R'. Better now? :-)
If you can, the output from pacman with the --debug flag would be useful, along with a specific version.
I'm using pacman 3.0.1 from testing. For the --debug flag, it'll take a while, since I have to remove the package during the conflict checking, which is a pretty short time. A moment earlier and it won't start the update, a moment later and it'll be locked by root. bardo
On 4/10/07, bardo <ilbardo@gmail.com> wrote:
On 4/10/07, Dan McGee <dpmcgee@gmail.com> wrote:
Well I don't know that this is a bug if you started doing that. We'd need a much better bug report and a way to reproduce it.
Ok, I think I didn't make myself clear in the first place, and then I misinterpreted your reply. I didn't run pacman twice. I removed the *package file* I was installing with 'rm', I never called 'pacman -R'. Better now? :-)
If you can, the output from pacman with the --debug flag would be useful, along with a specific version.
I'm using pacman 3.0.1 from testing. For the --debug flag, it'll take a while, since I have to remove the package during the conflict checking, which is a pretty short time. A moment earlier and it won't start the update, a moment later and it'll be locked by root.
Ah, correct, I did not understand you the first time. Does my comment on this not being a bug still stand? I guess I would almost categorize this as a feature request (not to paint a bikeshed here) to have pacman hold a lock (file descriptor) on all files from the get-go so this situation can never happen. The chances of it happening are pretty rare to begin with. -Dan
On 4/10/07, Dan McGee <dpmcgee@gmail.com> wrote:
Does my comment on this not being a bug still stand? I guess I would almost categorize this as a feature request (not to paint a bikeshed here) to have pacman hold a lock (file descriptor) on all files from the get-go so this situation can never happen. The chances of it happening are pretty rare to begin with.
Mmmh... I'm not sure if this is a bug or not, I'll let you guys decide. Anyway, I managed to debug it. Kids, don't do this at home, it killed my machine once, and only cpulimit saved me the second time :) The operation on which pacman locks is the following: debug: removing DB testing, 5 remaining... debug: returning error 22 from alpm_db_unregister : transaction already initialized This gets repeated ad infinitum, and I didn't manage to save the previous lines since even with a 1% cpu limit my 100.000 lines backlog scrolls too fast. Damn, guys, you should write slower code for pacman ;-) bardo
participants (2)
-
bardo
-
Dan McGee