Summary: | portage-2.0.51-r15 takes an incredibly long time to emerge | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | John Altstadt <altstadt> |
Component: | New packages | Assignee: | Portage team <dev-portage> |
Status: | VERIFIED TEST-REQUEST | ||
Severity: | minor | ||
Priority: | High | ||
Version: | unspecified | ||
Hardware: | x86 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
John Altstadt
2005-01-26 10:01:27 UTC
Did you check your dmesg? Make sure there weren't disk errors. That part does use a lot of IO. I just reran this emerge and checked in on top every once in a while. It appears that the main action that happens during the "Compiling python modules..." phase is that chown runs for about 5-10 minutes and then chmod runs for another 20-25 minutes. During that time: - there were no seek noises from my hard drives - nothing was added to dmesg - the only syslogs were recording cron jobs launching every 10 minutes - top said that the CPU was 97% idle typically - when chown was running, top said it consumed 1-4% of the CPU with a load average around 1.1 - when chmod was running, top said it consumed 0-4% of the CPU with a load average around 2.8 - the last time I saw chmod running, it had consumed about 8.5 CPU seconds over 20+ minutes of wall clock time - top usually consumed the most CPU at around 2% the whole time time emerge portage returned with real 33m32.747s user 0m24.300s sys 0m17.990s I'm running with reiser 3. Perhaps there are issues with changing file ownership and permissions with reiser, but I haven't noticed that any bulk chown or chmod commands took a long time before. I will try again with strace. As expected, strace shows a fork and wait on ebuild.sh, and then the strace output stops during the "Compiling python modules..." phase. Oh well. Short of hooking up gdb, I'm not going to be able to give you any more info. Curious that chown and chmod don't want to execute in a timely fashion. Did you ever resolve this issue? Did you try running chown and chmod yourself? No, this was never resolved. It looks like the recursive chown/chmod of /var/tmp/ccache (in the pkg_postinst section of the ebuild) takes an absurd amount of time to run. While it is running, it doesn't look like any CPU or I/O is being used. It would be interesting to find out if it acts the same way with other filesystems. I ran the chown command from the ebuild manually to get the info above. The ebuild no longer does these chowns. However, they do occur in portage itself. They should only ever happen when changing FEATURES="userpriv" on and off, however. I just emerged portage-2.0.51.21-r1. It took less than a minute. This is a massive improvement. Is there any sort of "go get a coffee" message printed by portage when it determines that it needs to run the chown/chmod? I just emerged portage-2.0.51.21-r1. It took less than a minute. This is a massive improvement. Is there any sort of "go get a coffee" message printed by portage when it determines that it needs to run the chown/chmod? Actually, nothing is printed. I should probably add that. |